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1.0  Introduction 

v  T 

The  purpose  of  this  contract  was  to  "examine  the  soldier-r achine 
interface  of  automated  battlefield  intelligence/^  systems  including 
optimization  of  operator-computer  protocols,  The  work  statement 
tasks  to  support  this  effort  were: 

lj  storyboard  the  application  demonstration  based  on  the  scenario 

developed  by  HEL/AAAD.  This  shall  include  the  selection  of  one  or 
two  operator  tasks  and  shall  use  the  specific  data  presented  in 
the  scenario; 

2 )  ~  analyze  the  operator  tasks  to  determine  the  possible  alternative 
protocols  which  could  be  used  to  execute  them.  Ideally,  the 
chosen  tasks  are  ones  for  which  more  than  one  protocol  can  be 
used ; 


3)  1  design  data  display  formats,  corresponding  to  different  protocol 

types,  for  the  operator  tasks; 

4)  >-  write  the  graphics  routines  and  author  the  GHMI  system  to  provide 

for  the  demonstration  of  the  tasks.  This  shall  include  being  able 
to  demonstrate  the  alternative  protocols  for  the  same  task; 

5) *-  integrate,  test  and  debug  the  demonstration; 

6  -  host  a  one-day  meeting  with  HEL/AAAD;  and 

7  *  document  the  effort,  providing  descriptions  of  the  operator  tasks, 

the  alternative  protocols  used,  pictures  (or  photographs),  and 
recommendations  for  future  studies.  ^ _ 

The  first  five  tasks  are  discussed  in  Sections  1.0  through  5.0  of  this 
report.  Specific  research  questions,  raised  during  the  de~ onstration 
development  effort,  are  discussed  in  Sections  3.0  and  4.0;  general 
considerations  for  future  research  are  described  in  Section  5.0.  A 
summary  of  the  one-day  meeting  held  at  Lockheed  on  7  December  1S94 
appears  in  Section  7.1  (Appendix  1). 


2.0  Data  Analyses,  Task  Selection,  Demonstration  Specification 


To  support  development  of  a  protocol  demonstration,  the  HEL  Aviation 
and  Air  Defense  Directorate  (HEL/AAAD)*  provided  a  one-half  hour 
"slice"  of  a  Short  Range  Air  Defenses  System  Command  and  Control 
(SHCRADS  C2)  scenario.  The  data  provided  by  HEL/AAAD  coneiited  of 
friendly  and  enemy  air  tracks,  t^e  deployment  of  an  ADA  Heavy  Division 
3H0RAD  battalion  (reduced  by  20X  cue  to  battle  attrition)  i  r.  the  area 
of  interest,  and  chronologically-ordered  message  traffic  be  -r.d  from 
the  Air  Battle  Management  Operations  Center  (AB15QC).  The  t ,  .a  and 
qv  intity  of  the  ABM0C  messages  were  developed  in  aooor  '  inc*  -i*.h  the 
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benchmark  requirements  specified  in  HIS  34585,  "SHORAD  C2  System 
Specification"  (10  October  1983). 

The  initial  task  on  this  contract  vas  the  analysis  of  these  data  to 
understand  the  battlefield  situation  (deployment  of  friendly  fire 
units,  sensors  and  other  assets,  unit  organization,  battlefield 
geometry),  and  the  message  flow  in  and  out  of  the  ABMOC  during  the 
half-hour  period.  Due  to  the  limited  funding  available  for  execution 
of  this  contract,  it  vas  decided  that  it  would  not  be  possible  to 
include  air  track  data  and  track-related  messages  in  the 
demonstration. 

A  picture  of  the  battlefield  situation  specified  by  the  scenario  data 
is  presented  in  Figure  1.  The  breakdown  of  T0-ABM0C  messages 
(messages  sent  from  other  SHORADS  C2  nodes  to  the  AMBOC)  and 
FR0M-ABM0C  messages  (messages  composed  at  the  ABMOC  and  addressed  to 
other  nodes)  during  the  half-hour  period,  and  a  few  examples  of  each 
type,  are  shown  in  Tables  1  and  2,  respectively. 

It  became  obvious  after  plotting  the  battlefield  situation  that  a 
means  for  selectively  displaying  different  battlefield  features  would 
be  important.  This  would  allow  the  user  to  declutter  the  display  of 
information  so  that  only  those  data  that  were  relevant  at  some 
particular  moment  would  be  presented.  Therefore,  a  method  for 
decluttering  the  situation  display  was  designed  and  demonstrated.  As 
we  were  developing  this  part  of  the  demonstration,  it  became  apparent 
that  details  of  the  situation  display,  such  as  unit  designations, 
would  not  be  discriminable  when  the  full  battlefield  (a  70km-X-70km 
area)  was  presented,  and,  if  shown  on  the  full  map,  would  only  add 
clutter  without  adding  any  information.  This  led  us  to  developing  a 
method  for  "blowing  up"  a  smaller  section  of  the  map  where  detailed 
information  would  be  provided.  Details  of  this  part  of  the 
demonstration  are  described  in  Section  3. 0. 

Based  on  the  data  that  were  provided  (situation  display  and  messages), 
prior  discussions  with  former  AD  personnel,  and  previous  experience 
with  the  SHORADS  C2  operational  concept,  it  seemed  that  the  situation 
display  was  the  most  important  piece  of  information  to  ABMOC  personnel 
and  that  a  user  would  be  assisted  if  his  message  processing  tasks 
could  be  performed  without  requiring  that  he  look  someplace  other  than 
at  the  display  (such  as  at  a  keyboard).  We  also  imagined  that  the 
u^er  "thinks"  primarily  in  spatio-temporal  terms:  he  is  most  often 
concerned  with  elements  and  events  occurring  at  some  location  at  some 
point  in  time.  All  scenario  messages  provided  to  us  as  data  were 
ropr ecc-nted  in  alphanumeric  form.  If  a  user  actually  had  to  read  and 
compose  alphanumeric  messages,  we  anticipated  that  he  would  experience 
the  following  problems: 

conversion  of  location  information  (e.g. ,  FH3S8243)  from 

alphanumerics  into  an  x-y  coordinate  on  his  display,  and  vice 
versa,  would  be  a  cognitively  difficult  and  demanding  task. 
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since  he  could  not  be  looking  simultaneously  at  two  places,  reading 
or  composing  a  message  would  require  that  he  take  his  eyes  away 
from  the  situation  display,  and 

the  user's  "mental  workload"  would  be  increased  by  having  to 
mentally  correlate  a  particular  (graphically  displayed)  unit  with 
the  message  it  sent,  or  was  to  receive. 

These  considerations  led  us  to  focus  our  protocol  design  efforts  on 
methods  which  would  represent  message  information  in  graphical  forms 
and  would  minimize  both  the  distance  and  the  frequency  with  which  the 
user  would  have  to  move  his  eyes  from  the  the  situation  display. 

Since  it  was  not  possible  to  demonstrate  processing  for  all  message 
types,  the  subset  selected  and  their  implementation  order  were 
determined  by  the  frequency  of  message  type,  the  relative  importance 
of  the  message  type,  and  the  opportunity  provided  by  the  message  type 
to  demonstrate  certain  interactive  protocol  features  that  we  consider 
to  be  important.  (Appendix  2  contains  R.  E.  Knox  and  R.  Erandau 
"Interactive  protocols  for  generalized  human-machine  interface;"  \t 
presents  a  general  discussion  of  protocol  design  issues. )  In  the  time 
provided,  it  was  possible  to  demonstrate  all  TO-ABMOC  messages  for 
which  an  implementation  order  is  shown  in  Table  1  (Message  ID  #1,  4, 

12,  20,  29);  of  the  FR0M-ABM0C  messages,  only  Movement  Order 
composition  was  demonstrated. 

No  alternative  protocols  were  demonstrated  for  the  same  message  type, 
though  different  protocol  types  (e.g. ,  "picking",  "locating")  are  used 
for  different  tasks.  A  discussion  of  possible  alternative  protocols 
and  analytic  arguments  for  why  they  would  be  less  desirable  (i.e. , 
human  performance  would  suffer)  are  presented  in  Section  4.0. 

3. 0  Description  of  Demonstration 

The  hardware  and  software  facilities  used  for  this  demonstration  were: 

a  DEC  PDP-11/70  (used  for  the  simulation  of  message  traffic 
described  in  section  3.2);  simulation  software  is  written  in  Pascal 
2  (Oregon  Software,  Inc.)  and  runs  under  the  RSX- 11M-PLL3  (DEC) 
opera  ling  system; 

a  Codata  68000-based  system  (used  for  control  of  the  "AEhOC" 
console);  software  developed  on  this  system  runs  under  the  UNIX 
(Bell  Laboratories)  operating  system;  some  application  processing 
code  is  written  in  the  C  language;  all  interactive  graphics 
software  is  written  in  Easel  (Interactive  Images  Incorporated); 
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Figure  1 

Scenario  Battlefield  Situation. 
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Table  1 

TO-ABMOC  Messages 


ID 

# 

TYPE  OF  MESSAGE 

Count 

(*) 

IMPLEMENTED 

Warnings 

VIS/AUD 

ACK 

Reqt. 

1 

(Air  Defense  Warning): 

1 

4th 

X 

X 

X 

4 

(Battlefield  Geometry): 

1 

3rd 

- 

- 

- 

5 

(Data  Link  Reference  Point): 

2 

X 

- 

- 

9 

(Enemy  Activity  Report) 

1 

X 

- 

- 

12 

( Kill  Report ) : 

8 

2nd 

X 

- 

- 

19 

( Pointer ) : 

1 

X 

- 

X 

20 

(Reporting  Unit  Location): 

44 

1st 

- 

- 

- 

23 

(Supply  6  Equip.  Status  Rept. ) : 

3 

X 

- 

- 

24 

(Track  Management): 

6 

NO 

• 

- 

- 

27 

(Unit  Operational  Report): 

3 

X 

- 

- 

28 

(Warning  Report): 

5 

X 

- 

X 

29 

(Weapon  Control  Order): 

1 

5th 

X 

— 

X 

Examples 


1045  (Scenario  Time) 

1.  FROM: 

TO  J 

MESSAGE  TYPE: 
MESSAGE: 


FAAR  A 
ABMOC 

20  (Reporting 
GRID  FH215354 


Unit  Location) 
ALT  299 


( PLRS )  ) 


1046 


2.  FROM: 

TO: 

MESSAGE  TYPE: 
MESSAGE: 


1/4/A 

ABMOC 

20  (Reporting  Unit 
1/4/A  to  FH200332 


Location ) 


1046 


3.  FROM: 

TO: 

MESSAGE  TYPE: 
MESSAGE: 


2/4/A 

ABMOC 

12  (Kill  Report) 
FW  1  DTG  231046 


(F/S) 


8 


Research  on  Interactive  Protocols 
Lockheed  Electronics  Company 


Table  2 

FROM-ABMOC  Messages 


ID  Count 

#  TYPE  OF  MESSAGE  <#>  IMPLEMENT 


6  (Data  Management): 

11  (IFF/SIF  Effective  Code) 
13  (Movement  Order): 

21  (Sensor  Management) : 

22  (Summary  Unit  Status): 

24  (Track  Management): 


1  2nd 

1 

9  1st 

1 

1  3rd 

9  NO 


Examples 


FROM:  ABMOC 
TO:  FAAR  A 

MESSAGE  TYPE:  13  (Movement  Order) 

MESSAGE:  FAAR  A  from  FH  215354  to  FH  116360  at  231000,  GS 


FROM:  ABMOC 
TO:  E  Btry 

MESSAGE  TYPE:  13  (Movement  Order) 

MESSAGE:  Move  weapons  to  FH  538082 


FROM:  ABMOC 
TO:  A  Btry 

MESSAGE  TYPE:  6  (Data  Management) 

MESSAGE:  Data  Update  Request:  Supply/Equip  Status 
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the  Generalized  Human  Machine  Interface  console;  the  devices  used 
for  this  demonstration  were  the  Mitsubishi  1024-X-1024  color 
display,  overlaid  by  a  high  resolution  Elographics  touch  screen, 
and  a  Prose  2020  Text-to-Speech  synthesizer  < Telesensory )  ;  the 
Motorola  monochrome  display  was  used  only  to  display  a  ’trace'  of 
the  incoming  alphanumeric  messages  that  were  being  converted  and 
displayed  on  the  color  monitor. 

The  following  sections  describe  the  demonstration  and  the  protocol 
conventions  used  for  the  different  tasks  that  were  implemented. 
Obviously,  to  control  the  length  of  this  document,  the  description  is 
not  exhaustive;  rather,  we  will  provide  more  detail  where  important 
issues  of  interactive  protocol  design  arise. 

3. 1  Situation  Display 

Figure  2  shows  a  photograph  of  the  beginning  display  screen  for  the 
demonstration.  [All  Figures  which  are  photographs  are  included  as 
Appendix  7.3  of  this  document].  The  dedicated  and  variable -assignment 
regions  of  the  software-programmable  interactive  display  screen  are 
defined  in  Figure  3.  The  weapons  control  and  air  defense  warning 
(ADW)  states  at  the  beginning  of  the  half-hour  slice  (time  is  1045) 
are  shown  at  the  top  right  of  the  screen;  note  that  redundant  coding 
of  the  ADW  is  accomplished  through  color. 

We  have  adopted  the  convention  that  binary-function  keys  (e.g. , 
on-off,  display-no  display)  are  coded  by  a  box  surrounding  the 
function  label  (whether  that  label  is  alphanumeric  or  graphic); 
functional  state  changes  are  accomplished  by  directly  touching  the 
software  key  on  the  display  screen.  The  enabled  state  of  the  function 
(e.g.,  "on,"  "display")  is  coded  as  a  change  from  white  lettering  on 

different  colored  backgrounds  (used  to  code  other  information,  as 
discussed  below)  to  reverse-video  black  lettering  on  a  green 
background.  In  Figure  2,  the  main-menu  at  the  bottom  of  the  screen 
indicates  that  the  "SET-UP-DISPLAY"  function  is  active. 

The  SET-UP-DISPLAY  menu  is  Bhown  in  the  variable  function  area  on  the 
right  of  the  screen.  For  demonstration  purposes,  we  chose  a  default 
starting  state  in  which  no  friendly  assets  are  displayed;  this 
decision,  of  course,  was  arbitrary  and  could  be  modified  tc  show  those 
elements  that  are  meaningful  at  system  initialization. 


Figure  3 

Software -programmable  interactive  display  screen  layout. 


DEDICATED 

STATUS 

REGION 


RESERVED 

MESSAGE 

REGION 


VARIABLE- 

ASSIGNMENT 

REGION 


11 


R-:-;;jarch  on  Interactive  Protocols 
Lockheed  Electronics  Company 


The  top  section  of  the  menu  shows  a  breakdown  of  assets  by  unit  type 
< i .  e.  ,  DIVAD-'DVAD",  STINGER- " SING " ,  CHAPARRAL- "CHAP’,  and  COMPAND 
PGSTS-"C  P*)  and  Task  Organization  ( Brigades- " BDE",  Task  Force-"TF 
ELY",  and  Division  Troops-"DIV  TRP*);  cells  within  the  matrix  show  the 
breakdown  to  the  battery  level  organization.  The  asset  and  task 
organization  main  levels  are  differentiated  from  the  battery-level 
breakdown  by  using  white  keys  on  a  blue  background;  it  also  provides 
visual  emphasis  to  the  fact  that  pressing  row  or  column  keys  will 
cause  all  elements  within  a  row  or  column  to  be  displayed.  If  the 
user  wished  to  see  all  units,  he  would  press  the  ALL  key  in  the 
upper-left  of  the  matrix  and  all  units  would  be  displayed  as  shown  in 
Figure  4.  If,  at  this  point,  he  wished  to  display  only  DIVAD  units, 
he  has  at  least  two  methods  of  doing  so:  (1)  press  the  ALL  key  once 
again  to  erase  all  units,  and  then  press  the  DVAD  key  to  display  on  iy 
DIVADs,  or  (2)  press  the  STNG,  CHAP,  and  C  P  keys  to  return  them  to  an 
off  state  (i.e. ,  erase  those  units  from  the  display),  leaving  only  the 
DIVADs  displayed.  This  final  state  is  shown  in  Figure  5.  In  terms  of 
the  number  of  key  presses  required,  method  (1)  is  more  efficient;  on 
the  other  hand,  if  the  user  wished  to  see  each  unit  type  as  it  was 
being  removed  in  the  process  of  displaying  only  the  DIVADs,  he  would 
use  method  (2).  The  point  is  that  one  cannot  define  efficiency  simply 
in  terms  of  the  number  of  key  presses  required. 

The  lower  section  of  this  menu  allows  the  user  to  selectively  display 
ASSETS  and  Battlefield  Geometry  ( BTFLD  GEO)  features.  The  full 
battlefield  situation  with  all  features  displayed  is  shown  in  Figure 
6.  Note  that  the  FLOT  label  appears  in  the  BTFLD  GEO  submenu,  but  no 
box  surrounds  it.  Following  our  convention,  this  would  imply  that  the 
user  cannot  display  the  FLOT.  In  fact,  in  this  scenario,  the  FLOT  is 
not  defined  until  it  arrives  as  a  Battlefield  Geometry  message  at 
about  1055;  we  describe  in  Section  3. 2  how  the  FLOT  key  is  made 
available  to  the  user  when  the  information  is  available  for  display. 

The  symbols  used  for  representation  of  battlefield  geometry  features 
follow  the  conventions  specified  in  FM  21-30,  "Military  Symbols."  For 
unit  symbols,  we  had  originally  U3ed  the  symbology  defined  in  Appendix 
V  of  MIS  34585  (see  Reference  Ill).  This  symbology  does  net 
differentiate  among  the  different  kinds  of  fire  units;  we  think  such 
differentiation  is  necessary.  We  did  not  want  to  color-coc'e  the 
symbols  because  of  the  limited  number  of  colors  available  that  can  be 
easily  distinguished.  Therefore,  we  adopted  a  simplified  shape-coding 
scheme:  DIVADs  were  rectangles,  STINGERs  were  triangles,  ar.d 
CHAPARRALs  were  squares;  all  friendly  fire  units  were  color -coded 
aqua.  The  four  FAARs  were  shape-coded  as  diamonds.  A  picture  of  the 
battlefield  situation  using  this  coding  is  shown  in  Figure  7.  During 
the  demonstration  meeting  with  HEL/AAAD  personnel,  it  was  suggested 
that  we  use  the  standard  air  defense  symbology;  the  battlefield 
.situation  using  this  coding  is  shown  in  all  preceding  photographs 
other  than  Figure  7.  While  our  subjective  impression  is  that  the 
simplified,  geometric  shapes  are  much  easier  to  discriminate,  the  use 
of  a  standard  symbology  would  be  required  in  on  op  .-rational  netting. 
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The  large  situation  display  only  shovs  unit  designation  labels  for  the 
Battery  Command  Posts;  adding  the  three-  to  four-character 
alphanumeric  unit  labels  to  the  large  display  would  have  aided  a  great 
deal  of  clutter.  Yet,  in  an  operational  setting  it  will  certainly  be 
necessary  at  times  to  know  specifically  who  a  unit  is,  or  to  inspect 
an  area  of  concern  in  greater  detail.  With  this  in  mind,  s  added  the 
INSPECT  function  which  expands  an  area  of  the  situation  r.-.:  and 
displays  it  in  the  variable  function  area.  Figure  8  shews  the  user 
pre-pt  after  the  INSPECT  function  key  has  been  pressed.  The  user  now 
touches  an  area  on  the  situation  display  and  an  approximately 
9  km-by-9  km  area,  centered  on  the  touch  location,  appears  in  the 
auxiliary  map  area,  as  shown  in  Figures  9a  (geometric  shape  coding) 
and  9b  (standard  AD  symbology).  Note  that  map  symbols  are  enlarged 
and  unit  designation  labels  are  added.  It  has  been  suggested  that  we 
might  have  shown  the  blow-up  of  the  situation  display  directly  on  the 
large  map;  we  chose  not  to  do  this  as  the  detailed  map  would  obscure  a 
large  section  of  the  current  situation;  we  judged  this  to  be 
undesirable  from  an  operational  point  of  view. 

3. 2  TO-ABMOC  Message  Processing 

All  TO-ABMOC  messages  were  converted  to  an  on-line  data  base  residing 
on  a  PDP-11/70.  A  small  "communications  network"  simulation  program 
was  written;  it  reads  the  time  at  which  TO-ABMOC  messages  are 
"received"  (from  the  message  data  base),  and  send3  the  set  of  messages 
occurring  during  each  one-minute  interval  to  another  computer  (a 
Codata  68000  system)  where  the  ABMOC  "console*  demonstration  was 
i  m  Pi  emented. 

Five  message  types  were  selected  for  demonstration;  these  accounted 
for  55  of  the  76  incoming  ABMOC  messages  during  the  half-hour 
scenario.  The  principles  guiding  the  design  of  message  representation 
were : 

to  reduce  the  amount  of  alphanumeric  data  to  be  read, 

to  develop  graphic  representations  of  messages  that  were  integrated 
with  the  situation  display  whenever  possible,  and 

to  -spatially  integrate  (i.e.,  co-locate)  new  information  and 
user - input  requests  with  existing  information. 

I  - -p  1  em-.-nt  at  ion  of  these  principles  are  described  in  the  next  five 
c act  ions. 

3.  21  R  -porting  Unit  Location 

Of  the  76  messages  received  during  the  half-hour  interval,  44  were 
updates  on  friendly  asset  positions.  An  example  of  a  "reporting  unit 
location"  i.e-oe  ge  is  shown  in  Table  3  (for  clarity,  most  baotl- -field 
situation  features  that  are  irrelevant  to  this  and  sub.  >que:.t  examples 
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of  message  processing,  have  been  removed  from  the  screen).  In 
representing  position  changes  graphically,  we  chose  to  indicate  both 
the  old  and  the  new  locations  (or,  in  the  case  of  FAAR  updates,  old 
and  new  altitudes);  if  it  is  important  to  know  hov  far  and  from  where 
a  fire  unit  has  moved,  both  locations  would  have  to  be  indicated.  If 
both  locations  are  to  be  observed,  they  must  be  displayed  for  some 
period  of  t  ime.  Finally,  the  user  must  be  able  to  distinguish  between 
the  old  location  and  new  location  indicators;  hence,  they  rust  be 
coded  in  a  discriminable  fashion. 


Table  3 

Example  of  Reporting  Unit  Location  Message 


1046  (Scenario  Time) 


FROM: 

TO: 

MESSAGE  TYPE: 
MESSAGE: 


2/4/  B 
ABMOC 

20  (Reporting  Unit  Location) 
2/4/B  to  FH473215 


Figure  10a  shows  an  example  of  an  old  and  new  location  of  a  STINGER 
unit;  the  old  location  is  indicated  by  the  green  STINGER  symbol  and 
the  new  location  is  indicated  by  the  oversized  (relative  to  other 
symbols)  green  square.  Green  was  used  to  highlight  the  two  symbols. 

It  was  chosen  because  of  the  eye's  greater  sensitivity  to  wavelengths 
in  the  mid-range  of  the  visible  spectrum;  yellow  was  not  used  because 
its  widespread  use  to  indicate  cautionary  states.  Both  symbols  remain 
visible  for  about  five  seconds;  afterwards,  the  aqua  STINGER  symbol  is 
displayed  in  the  new  location,  as  shown  in  Figure  10b. 

3. 22  Kill  Report 

Kill  reports  specify  the  unit  reporting  the  kill(s),  the  type  (fixed 
or  rotary  wing)  and  number  of  aircraft  downed,  and  the  date-time  group 
(DIG)  of  the  report;  an  example  of  such  a  message  is  shown  in  Table  4. 
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Table  4 

Example  of  Kill  Report  Message 


1046  (Scenario  Time) 

FROM:  2/4/A 
TO:  ABMOC 

MESSAGE  TYPE:  12  (Kill  Report) 

MESSAGE:  FW  1  DTG  231046  (F/S) 


[  Figure  11  presents  an  example  of  a  graphics  representation  of  such  a 

message.  The  STINGER  unit  (2/4/A)  reporting  the  kill  is  surrounded  by 
a  yellow  box.  The  "report*  itself  is  displayed  in  the  upper  right  of 
the  situation  display:  the  AD  fixed-wing  aircraft  symbol  denotes  the 
type  of  the  downed  aircraft,  the  X  above  it  is  the  conventional 
•destroyed"  indicator,  and  the  DTG  of  the  report  is  shown  at  the 
bottom  of  the  composite  symbol.  The  yellow  color  coding  was  used  for 
distinctiveness,  to  associate  the  unit  reporting  the  kill  with  the 
report  itself  (this  may,  in  fact,  add  information  about  the 
approximate  location  of  the  kill),  and  for  its  implication  of  a 
cautionary  state. 

A  kill  report  remains  displayed  until  a  new  one  is  received  (see 
Appendix  1  for  a  brief  discussion  of  when  data  should  be  removed  from 
the  display  screen).  Kill  reports  would  not  necessarily  always  be 
displayed  in  this  portion  of  the  display  (we  put  it  there  because  it 
would  occlude  no  other  data);  rather,  we  anticipate  that  "smart" 
software  would  "find"  the  sparsely  used  portions  of  a  situation 
display,  and  would  plot  such  data  to  minimize  the  overlay  of  other 
relevant  situation  information.  Kill  reports,  then,  would  probably  be 
presented  at  different  locations  as  the  scenario  progressed.  Rather 
than  creating  confusion,  we  expect  that  such  shifting  in  location 
would  call  attention  to  the  arrival  of  new  information.  (In  fact,  one 
criticism  of  the  demonstration  was  that  it  was  hard  to  tell  when  a  new 
kill  report  had  been  received  since  the  data  always  appeared  in  the 
same  location. ) 

3. 23  Eattlefield  Geonetry 

The  one  Eattlefield  Geometry  message  received  during  the  half  hour 
provides  a  ten-point  definition  of  the  FLOT ;  the  message  is  shown  in 
Table  5.  In  the  demonstration,  this  message  wa3  converted  to  the  FLQT 
contour  and  plotted  on  the  situation  map;  it  i3  color-coded  blue  to 
signify  that  it  borders  friendly  assets  and  to  differentiate  it  from 
the  r  >d  FEBA.  Figure  12  shows  thi3  representation. 
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Table  5 

Example  of  Battlefield  Geometry  Message 

1053  (Scenario  Time) 

FROM:  (D)AME 
TO:  ABMOC 

MESSAGE  TYPE:  4  (Battlefield  Geometry) 

MESSAGE: 


REFERENCE  NUMBER:  ADA4 

EFFECTIVE  TIME:  Upon  Receipt 

TYPE:  FLOT  10  POINTS 

LOCATION:  From  FH270430  to  FH270365  to  FH270298 

to  FH350254  to  FH407244  to  FH468214 
to  FH520178  to  FH522158  to  FK527097 
to  FH510068 


At  the  same  time,  the  FLOT  key  in  the  BTFLD  GEO  submenu  of  the  Set-Up 
Display  function  haa  been  enabled  and  set  to  the  display-state  (as 
indicated  by  black  lettering  on  a  green  background);  this  ia  also 
shown  in  Figure  12.  The  key  is  now  fully  functioning  and  allows  the 
user  to  display  or  erase  the  FLOT  from  the  situation  display  as 
necessary. 

3. 24  Air  Defense  Warning 

One  Air  Defense  Warning  (ADW)  is  received  during  the  scenario;  the 
message  is  shown  in  Table  6.  When  an  ADW  is  distributed,  visual  and 
auditory  alerts  must  be  issued  to  the  user;  he,  in  turn,  is  required 
to  manually  (i.e.,  explicitly)  acknowledge  that  he  has  received  the 

message. 
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Table  6 

Example  of  Air  Defense  Warning  Message 

1055  (Scenario  Time) 

FROM:  HIMAD 
TO:  ALL 

MESSAGE  TYPE:  1  (Air  Defense  Warning  Report) 

MESSAGE:  AIR  DEFENSE  WARNING  CONDITION:  RED 


Figure  13  chows  the  change  to  the  ADW  indicator  in  the  status  region 
at  the  upper  right  of  the  display  screen.  The  instruction  to 
acknowledge  receipt  of  the  ADW  is  presented  in  the  reserved  message 
region  just  below  the  status  region.  The  auditory  alert,  presented 
simultaneously  with  the  ADW  change  and  annunciated  by  the 
text-to-speech  voice  synthesizer,  consists  of  the  following  message: 

•Warning!  Air  Defense  Warning:  Condition  Red.  Please  Acknowledge. " 

Notice  that  the  visual  and  auditory  alerts  carry  explicit  information 
about  the  message  requiring  the  user's  attention;  often,  visual  and 
auditory  alerts  simply  consist  of  non-specific  flashing  indicators  and 
auditory  "beeps",  respectively.  We  think  an  explicit  auditory 
message,  in  particular,  is  advantageous:  the  information  can  be 
received  without  requiring  a  shift  in  visual  attention.  Of  course, 
there  could  be  drawbacks  to  the  use  of  such  auditory  messages  in  a 
battlefield  environment,  and  assessment  in  an  operational  context 
would  be  necessary  before  we  could  unequivocally  recommend  their  use. 

User  acknowledgement  of  ADW  receipt  was  accomplished  in  the  following 
manner.  Note  that  the  "RED"  ADW  is  presented  in  reverse-video  in  the 
rectangular  shape  of  a  key;  the  user  acknowledges  the  message  by 
directly  touching  the  ADW  status  indicator.  Once  he  does  so,  the 
"key*  is  disabled  (i.e.,  the  box  disappears)  and  the  instruction  to 
acknowledge  the  message  is  removed  from  the  reserved  message  region. 
Eoth  of  these  changes  are  shown  in  Figure  14. 

On  many  system 3,  all  operator  acknowledgments  are  accomplished  by 
pressing  a  single  key;  no  unique  response  is  required  to  differentiate 
among  the  different  messages  that  are  received.  We  think  our 
approach,  requiring  unique,  specific  responses,  which  also  force  the 
user  to  look  directly  at  the  new  information  he  is  acknowledging,  is 
preferable;  "hen  a  non-specific  response  is  required,  we  imagined  that 
a  user  could  often  is3ue  an  acknowledgment  without  even  looking  at  the 
message,  and  would  be  particularly  likely  to  do  30  when  message  lead 
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and  the  stress  of  the  situation  increase.  Messages  that  require  an 
operator's  acknowledgment  are  presumably  important;  precluding  the 
possibility  of  his  ignoring  them  reduces  the  potential  for  subsequent 
human  error. 

3. 25  Weapon  Control  Order 

One  Weapon  Control  Order  (WCO)  message,  shown  in  Table  7,  vas  issued 
during  the  scenario.  WCOs  are  accompanied  by  visual  alerts,  and,  as 
with  an  ADW  message,  user  acknowledgment  is  required. 


Table  7 

Example  of  Weapon  Control  Order  Message 


1056  (Scenario  Time) 

FROM:  HIMAD 
TO:  ALL 

MESSAGE  TYPE:  29  (Weapon  Control  Order) 
MESSAGE: 


ORDER  NO.  23-12 

AREA  NO. 

2A 

PRESENT 

STATUS 

NEW 

STATUS 

FW 

Hold 

FW 

Tight 

DEACT  TIME 

1210 

EFF  TIME 

1211 

RW 

Hold 

RW 

Tight 

DEACT  TIME 

1210 

EFF  TIME 

1211 

STATE  OF  ALERT:  Assume  Batt lestat ions 


For  demonstration  purposes,  we  showed  the  WCO  change  as  though  it  had 
just  become  effective  (rather  than  using  the  effective  time  specified 
in  the  message,  which  was  outside  of  the  half-hour  period  of  concern). 
In  a  fashion  similar  to  the  changes  effected  by  the  ADW,  the-  receipt 
of  the  WCO  caused  the  "FW*  and  "RW"  values  displayed  in  the  re  .-rved 
status  area  to  change  from  ’HOLD"  to  "TIGHT".  The  visual  pro  pt  to 
acknowledge  receipt  of  the  WCO  is  displayed  in  the  recervc-d  -  age 
area,  along  with  the  state  of  alert  me  cm  age  to  "A.orume 
Eatt lectations. ’  This  display  of  WCO  information  is  shown  in  Figure 
16. 


Though  an  auditory  warning  is  not  required  for  WCO  nee cages,  we 
provided  one  to  give  a  second  example  of  an  explicit  auditory 
indication.  The  auditory  alert  annunciated  by  the  text-tc-  h 

synthesizer  is: 
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•Note:  Change  of  Weapon  Control  Status; 

"Fixed  Wing:  From  HOLD  to  TIGHT; 

•Rotary  Wing:  From  HOLD  to  TIGHT; 

•Please  Acknowledge. 

"Alert:  Assume  Batt lestations. • 

Operator  acknowledgment  is  entered  the  same  way  as  acknowledgment  to 
an  ADW:  the  new  values  are  displayed,  enabled  as  keys,  and  the  user 
must  touch  both  the  FW  and  RW  values  to  indicate  he  has  seen  them. 

The  change  in  the  displayed  information  following  operator 
acknowledgment  is  shown  in  Figure  16. 

3. 3  FROM-ABMOC  Message  Processing 

FROM-ABMOC  message  processing  refers  to  message  composition  by  the 
ABMOC  operator.  This  function  can  be  activated  by  selection  of  the 
•COMPOSE  MESSAGE*  function  in  the  Main-menu;  the  submenu  of  all 
messages  that  can  be  created  by  the  ABMOC  appears  in  the 
variable-assignment  region  of  the  display  screen  (see  Figure  17). 
Messages  have  been  grouped  into  related-topic  clusters.  By  touching 
the  appropriate  name,  the  user  would  select  the  message  to  be  created. 
Only  movement  order  message  creation  was  developed  for  this 
demonstration;  this  is  reflected  by  the  presence  of  a  box  around  "MOVE 
ORDER"  --  signifying  that  it  is  an  enabled  key  --  and  the  absence  of 
boxes  around  all  other  message  labels.  The  movement  order  was 
selected  for  implementation  because  it  presented  an  opportunity  to 
demonstrate  a  number  of  interactive  display  techniques  for  data  entry. 

3. 31  Movement  Order 

Samples  of  various  movement  orders  are  presented  in  Table  8.  The 
message  fields  and  field-values  U3ed  in  the  demonstration  were  based 
on  the  particular  examples  provided  in  the  scenario;  methods  for 
entering  the  data  of  other  message  types  can  be  predicted  by 
generalizing  from  the  example  we  have  provided. 
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Table  8 

Examples  of  Movement  Order  Message 


FROM:  ABMOC 
TO:  FAAR  A 

MESSAGE  TYPE:  13  (Movement  Order) 

MESSAGE:  FAAR  A  from  FH  215354  to  FH  116360  at  231800, 
GS 


FROM:  ABMOC 
TO:  B  Btry 

MESSAGE  TYPE:  13  (Movement  Order) 

MESSAGE:  Move  weapons  to  FH  4222  to  FH  4422 


FROM:  ABMOC 
TO:  E  Btry 

MESSAGE  TYPE:  13  (Movement  Order) 

MESSAGE:  Move  weapons  to  FH  538082 


FROM:  ABMOC 
TO:  D  Btry 

MESSAGE  TYPE:  13  (Movement  Order) 

MESSAGE:  Place  PLT  DS  to  DISCOM  EFF  231200 


The  sequence  of  operations  for  generating  a  movement  order  (described 
b?low)  was  determined  by  analysis  of  the  movement  order  messages 
pi ovided.  We  considered,  but  did  not  address  a  number  of  issues, 
including : 

allowing  the  user  to  vary  the  order  in  which  he  enters  the 
parameters  of  a  movement  order  message, 

p irancter  field  "skipping"  (i.e.,  null  fields), 

how  to  provide  feedback  to  alert  the  user  to  the  fact  that  he  has 
skipped  a  field,  in  case  he  has  done  so  accidently,  or  has  made  an 
entry  that  is  "tactically  questionable"  (this  would  require 
intelligent  software  that  would  not  "blindly"  report  on  ~i£-,ing 
fields  or  blatant  errors,  but  would  parse  and  assess  a  message  for 
" r rnningf ulness" ;  such  assessment  would  depend,  for  exaple,  on  a 
knowledge  base  that  describes  how  assets  can  move  over  the  given 
terrain,  whether  the  move  is  "reasonable*  given  the  carr-nt 
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situation  and  the  location  of  recent  kill  reports,  whether  the  move 
will  introduce  vulnerabilities  in  the  defense,  whether  the 
specified  units  are  "robust"  enough  --  based  on  evaluation  of 
supply  and  equipment  reports  --  to  achieve  the  specified  mission, 
etc.  ),  and 

revision  of  a  composed,  but  not  yet  released  message. 

Clearly,  the  definition  of  an  interactive  protocol  for  movement  order 
and  other  message  creation  would  require  that  these  and  other  issues 
be  examined. 

The  first  movement  order  parameter  to  be  specified  is  the  name  of  the 
unit  who  is  to  move  his  assets.  Following  selection  of  the  MOVE 
ORDER  message  type,  a  menu  of  the  potential  candidates  appears,  as 
shown  in  Figure  18a.  Notice  that  the  menu  is  specific  to  the  ABMOC 
echelon.  Again,  for  demonstration  purposes  as  well  as  to  alleviate 
memory  demands  placed  on  the  user,  an  alphanumeric  representation  (a 
"trace")  of  user  inputs  is  displayed  at  the  top  of  the 
variable-assignment  region;  this  conversion  to  the  more  standard 
message  format  is  demonstrated  in  parallel  with  the  data  entry 
functions  described  below. 

The  user  is  prompted  for  an  entry  by  the  green-coded  "Wove  Who’  above 
the  menu  (following  the  conventions  of  this  demonstration,  it  is 
apparent  that  only  Movement  Orders  for  Batteries  (BTRYs)  and  FAARS 
were  implemented,  as  indicated  by  the  key- indicator  surrounding  their 
labels,  and  the  absence  of  a  box  around  the  other  SHORADS  C2  units  who 
can  be  commanded  by  the  ABMOC  to  change  location).  Suppose  the  user 
selects  A  BTRY;  as  shown  in  Figure  18b,  a  submenu  of  A  BTRY  assets 
appears  below  the  BTRY  column.  Had  the  user  selected  a  FAAR  instead, 
no  such  submenu  would  have  appeared  since  such  a  breakdown  is 
meaningless  for  sensors. 

In  this  example,  the  user  presses  the  WPNS  key  (indicating  that  we 
wants  A  BTRY  to  move  weapons),  as  shown  in  Figure  18c;  both  selections 
are  indicated  by  the  green  reverse- video  coding.  After  the  user 
presses  the  WPNS  key,  an  ENTER  key  is  displayed  to  the  right  of  the 
submenu.  The  availability  of  this  key  is  suppressed  (by  net 
dieplaying  it)  until  after  the  us?r  has  entered  sufficient  •  r.forr  jtion 
for  the  addressed  unit  to  be  specified.  When  it  is  possible, 
inhibiting  the  availability  of  keyB  until  they  are  logically 
meaningful  will  prevent  inadvertent  orinsion  of  required  dr.i. 

Until  the  user  presses  the  ENTER  key,  it  is  per.  ible  for  hi~  to  ch'-nge 


his  selections  for  either  the  primary  unit  name  or  the  unit’s  •  is. 

The  next  menu  of  choices  to  appear  allows  the  user  to  cpecify  v  ;•  re 
the  designated  asset  is  to  move.  This  "new  location"  menu  is  :  .  n  in 
Figure  19a.  Two  sets  of  choices  were  indicated  by  the  rove  r  t  •  .  '  :-r 
examples  in  the  scenario,  and  are  visually  clustered  on  the-  l  y. 
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POINT  and  LINE  allow  the  user  to  specify  location(s)  on  the  situation 
display;  the  listed  names  allow  entry  of  an  AD  unit,  without 
specification  of  the  unit's  location. 

Assume  the  ABMOC  wants  the  A  BTRY  weapons  moved  to  cover  a  line  near 
the  FEBA.  He  presses  the  LINE  key  and  ENTER  key  (see  Figure  19b),  and 
a  new  display  appears.  Figure  20a  shows  a  prompt  for  selection  of  a 
battlefield  area.  Rather  than  entering  positions  as  UTM  alphanumeric 
designations,  the  user  will  specify  a  battlefield  location  in  the 
"language"  of  the  situation  display  itself  by  directly  touching  a 
location.  Because  he  cannot  sufficiently  resolve  locations  on  the 
full-scale  map,  a  blow-up  of  the  desired  area  is  provided  in  the 
variable-assignment  area.  The  user  touches  the  general  area  of  the 
battlefield  where  he  wants  the  A  BTRY  weapons  to  be  deployed.  As  with 
the  INSPECT  function  (described  in  Section  3.1  above),  a  9  km-by-9  km 
area  is  displayed,  centered  on  the  location  of  his  touch  (see  Figure 
20b) ;  at  the  same  time,  he  is  given  a  prompt  to  "Select  first 
location"  (two  points  are  required  to  define  the  LINE).  The  area 
shown  in  the  high-resolution  situation  display  is  indicated  on  the 
full-scale  map  by  the  green  border. 

The  user  touches  the  high-resolution  display  to  designate  the  first 
point,  and  a  green  dot,  indicating  the  location  of  his  touch,  appears 
on  both  the  high-  and  low-resolution  displays  (see  Figure  20c).  This 
location  is  converted  to  UTM  coordinates  (e.g.,  FH368243)  and 
displayed  in  the  alphanumeric  representation  of  the  message.  The  user 
can  change  this  first  location  until  he  presses  the  ENTER  key. 
Following  entry  of  the  first  point,  the  user  is  prompted  for  entry  of 
the  second  point  (see  Figure  20d).  When  a  second  location  is  touched, 
a  second  green  dot  and  a  line  between  the  two  points  are  displayed. 
Again,  the  user  can  change  the  location  of  the  second  point  until  he 
presses  the  ENTER  key.  (Note:  the  scale  of  the  high-resolution 
situation  display  is  sufficient  to  specify  the  two-kilometer  lines  we 
observed  in  the  data;  if  it  were  necessary  to  specify  shorter  lines  -- 
i.e.,  two  points  with  less  than  a  two  kilometer  separation  --  a  higher 
resolution  "blow  up"  would  be  provided. ) 

Following  designation  of  the  line  to  which  A  BTRY  is  to  move  weapons, 
a  mission  must  be  specified.  This  is  accomplished  with  the  menu  shown 
in  Figure  21,  using  the  same  data  entry  protocol  described  for  all 
pi  ‘.-ceding  menu  .-l'-ctions. 

The  final  entry  inquired  is  specification  of  the  Date-Time  "roup  (DIG) 
at  which  the  movement  order  la  to  take  place.  These  data  are  entered 
using  the  low-resolution  (hour  intervals)  "digital"  clock  shown  in 
Figure  22;  an  analog  clock,  allowing  entries  to  minute  re-solution  is 
ri  -ct- nry  in  an  operational  situation,  and,  hence,  preferable;  one 
would  have  been  developed  had  more  time  been  available.  Note  that  the 
r ovei'-r-nt  is  assur-ed  to  be  required  sometime  during  a  two-day  p  .-nod, 
so  only  day  23  and  24  choices  are  displayed.  Movement  order  DTG 
P'-c  1  f  i  cat  ion  at  - -rhelcr.  3  other  than  A-3MQC  would  require  th  it  the 
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"day-window"  be  widened  (for  higher  echelons)  or  narrowed  (for  lower 
echelons ) . 


Regardless  of  which  Main-menu  function  is  being  used,  the  operator  can 


always  change  functions;  in  composing  a  movement  order,  for  exam  pie, 
the  user  might  want  to  move  assets  that  have  been  inhibited  from 
display  during  the  SET  UP  DISPLAY  operation.  The  user  would  select 
this  main -menu  function,  display  the  necessary  units,  return  to  the 
COMPOSE  MESSAGE  operation,  and  would  be  returned  to  the  exact  point  of 
movement  order  creation  where  he  had  left  off  to  change  the  situation 
display. 


Discussion  of  Alternative  Protocols 


There  was  insufficient 
message  creation.  Our 
screen  protocol,  howev 
method  is  preferable, 
and  "natural"  language 
would  also  cover  voice 
natural  language  modes 
justification  for  this 


time  to  demonstrate  an  alternative  protocol  for 
decision  to  demonstrate  an  interactive  display 
er,  was  not  arbitrary;  in  our  opinion,  the 
for  the  tasks  performed,  to  both  form-filling 
using  a  keyboard.  (A  more  extensive  discussion 
input,  used  both  in  "key"  replacement  and 
.  )  We  briefly  present  our  assumptions  and 
position. 


(1)  Ve  assumed  that  a  user  would  directly  select  a  location  for  a  movement 
order,  as  opposed,  for  example,  to  simply  performing  data  entry  of  a 
specified  UTM  coordinate.  In  this  latter  case,  data  entry  would 
require  a  numerical  keypad  and  a  special  alpha-matrix  to  designate 
coordinates  for  the  area  of  interest.  This  form  of  data  entry  could 
still  be  accomplished  with  a  modified  data  entry  keypad  displayed 
directly  in  the  variable-assignment  area  of  the  screen;  an  example  of 
such  a  data  entry  "device"  is  shown  in  Figure  23. 


CN’ote  that  the  convention  of  using  co-located  display  and  input 
control  surfaces  does  not  imply  the  use  of  a  touch  screen  overlay  to 
the  display;  any  cursor  positioning  device,  such  as  a  mouse  or 
trackball,  could  be  used  in  lieu  of  the  user's  finger.] 


The  d  .'Vice  must  be  distinguished  from  the  protocol  used  for  input. 

K  .‘/t  oar  ds  ray  be  used  for  menu-selection,  form-filling,  and  natural 
1  rrju  -nu -select  ion,  form-filling,  and  natural  languac?  may  all 

b?  : ; pi-  ntod  with  voice  recognizers.  The  use  of  a  particular  d. vice 
(  ;  not  uniquely  imply  the  use  of  a  particular  protocol;  c -fiver.-- ’ly, 

ere  of  a  particular  protocol  does  not  imply  the  use  of  3 


y,y:y; 
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(3)  The  use  of  a  menu-selection  protocol  implies  that  there  are  a  United 
number  of  choices  for  some  parameter's  value;  the  user  selects  one 
item  from  a  "list*  of  choices.  [A  "list*  is  an  enumeration  of 
options,  arranged  in  some  spatio-temporal  organization;  options  may  be 
represented  graphically,  alphanumer ica 1 ly,  aurally,  etc. ]  Analysis  of 
the  scenario  data  indicated  that,  with  the  exception  of  location  and 
time  specifications  ( for  which  none  of  the  above  mentioned  protocols 
would  suffice),  there  were  very  few  value  choices  for  each  of  the 
parameters  of  a  Movement  Order.  Whether  or  not  this  is  true  for  other 
massages  created  by  the  AEMQC,  for  all  other  nodes  of  the  SHORADS  C2 
system,  or  for  message  communication  in  any  system,  would  require 
detailed  analysis  of  possible  parameter  values  for  all  messages  in  a 
system.  tWe  are  familiar  with  Appendix  II  ("Information  exchanged  by 
the  SHORAD  C2  system")  and  are  aware  that  certain  parameters  of 
certain  messages  (o. g. ,  "Air  Track  Report:  AC  Type")  show  long  lists 
of  possible  values.  It  may  be  possible  to  break  down  these  lists  into 
more  logical  groupings;  further  analyses  would  be  necessary  to 
determine  if  this  is  operationally  beneficial. 

(4)  To  make  a  meaningful  distinction  between  form-filling  and 
renu-selection,  a  definition  of  form-filling  must  be  specified.  For 
example,  the  Movement  Order  creation  demonstration  showed  an 
alphanumeric  representation  of  the  data  being  entered;  the  entries 
were  placed  in  fixed  fields  of  an  invisible  template.  Had  the 
template  been  m=ide  visible,  the  operation  would  have  looked  very  much 
like  form-filling.  But  the  entry  of  data  was  accomplished  by 
menu-selection  and  "locating"  operations. 

We  restrict  the  definition  of  "form-filling"  to  mean  the  following: 
the  different  fields  of  a  message  may  be  specified,  but  the  possible 
values  for  at  least  some  of  those  fields  is  extremely  large;  the 
structure  of  the  message,  then,  is  fixed  and  specifiable,  but  value 
choices  may  not  be  practically  enumerated  (as  is  possible  with  menus). 
The  list  of  options  is  generated  in,  and  selected  from,  the  mind  of 
the  user.  Selection  of  a  value  from  a  (virtual)  continuum  (o.g., 
cutting  a  voltage,  naming  a  particular  individual  in  a  group  of  2000 
people)  is  an  instance  of  f or m- f i 1 1 1 ng. 

;5)  V'hy  did  we  avoid  use  of  a  keyboard?  First,  if  the  user  had  been 

required  to  fully  type  out  his  selections,  keyboard  entry  would  have 
h  -en  much  slower  than  the  direct  selection  method.  Mo  effective  entry 
<e.g.  ,  "A  BTRY",  "WP.'iS",  "DIRECT  SUVPORT",  etc.)  was  one  letter  in 
1  r.gth;  but  only  a  single  keypress  was  required  to  make  the  entry.  In 
all  cases,  multiple  keypresses  would  have  been  required  if  the 
elections  had  been  typed  out;  obviously,  such  an  approach  would  have 
taken  more  time,  and  introduced  errors  which  would  hive  had  to  be 
corrected.  The  approach  we  adopted  is  superior  to  full  keyboard 
entry. 


Lu  u  : 
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A  second  approach  would  have  been  to  match  the  number  of  keyboard 
stroke 3  to  the  single  button  presses  required  in  the  direct  touch 
screen  selection.  This  could  have  been  accomplished  by  labelling 
(e.g.,  "1",  *2",  or  "a",  "b",  etc.)  each  option  displayed  on  the 

screen.  The  user  would  press  the  key  on  the  keyboard  corresponding  to 
his  desired  choice.  Eoth  data  entry  methods  require  a  keypress,  but 
the  t  t  a  1  activity  required  of  the  user  in  the  two  casss  is  not 
identical.  A  comparison  of  the  sequence  of  "mental",  "perceptual", 
and  "cot or"  activities  required  by  the  two  methods  is  presented  in 
Table  9.  This  approach  to  the  decomposition  of  tasks  has  been 
described  by  Card,  Moran,  and  Newell  (see  Reference  [21 ).  We  note 
that 

the  particular  breakdown  of  choice  data  entry  into  the  subtasks 
presented  in  Table  9  is  supported  by  their  research;  each  of  the 
operations  listed  can  be  empirically  isolated  and  differentiated 
from  the  others,  and 

there  is  overwhelming  evidence  from  their  research  (and  from  the 
experimental  literature,  in  general)  that  each  of  the  subtasks 
enumerated  take  real  time  (varying  from  a  few  hundred  milliseconds 
to  a  second  or  more). 


Table  9 

Comparison  of  Keyboard  and  Interactive  Screen  Methods 
for  Data  Entry  of  Parameter  Choice 


Act  ion 


Keyboard 


Interactive  Screen 


ind  Choice  (read  options)  X 

cad  Label  of  Desired  Choice  X 

Move  Eyes  to  Keyboard  X 

Find  Key  Matching  Label  X 

Finger  to  Key  X 

F r js  Key  X 

R /  turn  Eyes  to  Dir pi ay  X 


X 


X 

X 


Me  t  r ilitary  p vroonnel  are  poor  typists;  it  would  take  them  longer  to 
< o  keyho.rd  data  entry  than  interactive  screen  data  entry.  < Whether 
or  not  it  would  take  longer  for  skilled  typists  is  an  empirical 

■jo,  )  Mince  the  selections  -and  data  entry  to  be  made  by  the  u  :?r  do 
not  re  juire  a  k  ybo-ird  (i.e.,  all  tacks  can  be  accomodated  by  the 
iot  r active  rcr  ?n  method),  there  is  no  justification  for  its  u  o.  In 
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fact,  the  prediction  of  longer  data  entry  times  are  an  argument 
against  its  use. 

Note,  by  the  vay,  that  the  superiority  of  the  interactive  screen 
method  does  not  depend  on  the  use  of  a  touch  screen  overlay,  which,  as 
others  have  quite  legitimately  argued,  can  result  in  fatigue  of  the 
user '3  arm  if  used  for  extended  periods  of  time.  A  mouse,  which  does 
not  produce  such  fatigue,  could  have  been  used  for  direct  screen 
interaction  for  selecting  options  or  designating  locations.  The 
critical  difference  between  interactive  screen  and  keyboard  entry 
techniques  is  that  the  latter  requires  the  user  to  look  away  from  the 
display  screen  while  the  former  does  not.  It  is  the  time  lost  in 
shifting  visual  attention,  and  in  performing  cognitive,  perceptual, 
and  motor  reorientation  to  different  display/control  devices  that 
argue  against  the  use  of  a  keyboard  when  the  tasks  to  be  performed  do 
not  require  one. 


5. 0  Future  Studies 

We  suggest  that  future  studies  on  interactive  protocols  address  the 
requirements  of  a  particular  application  (i.e.,  a  system,  like  SHORADS 
C2).  That  is,  a  detailed  functional  specification  of  the  user  tasks 
must  be  available  to  determine  which  kinds  of  protocols  and 
input/output  devices  should  be  considered.  In  the  preceding  section, 
our  justification  of  an  interact;  '  display,  menu-selection,  and 
locating  approach  depended  on  analyses  of  the  specific  data  that  were 
made  available.  If,  for  example,  the  SHORADS  system  had  a 
requirement  for  free-format  message  construction,  some  level  of 
"natural"  language  processing  and  use  of  a  keyboard  and/or  voice 
recognizer  would  be  required;  analysis  of  a  natural  language  protocol 
would  be  meaningful  in  such  a  context. 

Second,  the  experimental  context  in  which  protocols  are  evaluated  will 
determine  the  generalizability  of  the  results  to  an  operational 
context.  The  results  of  an  experiment  in  which  many  subjects  are 
sampled  for  short  periods  of  time  will  be  quite  different  from  a 
sample  of  a  few  subjects  who  are  run  for  extended  periods  cf  time. 

The  latter  methodology  is  appropriate  if  it  is  on-going  operational 
performance,  rather  than  novice  behavior,  that  i3  to  be  predicted. 

The  collection  and  analysis  of  data  from  such  an  operational  context 
>ould  require: 

on-line  (i.e.,  computer-based)  data  collection  and  analysis 
programs,  and 

an  operational  testbed  which  simulates  the  activities  of  the 
operational  situation  with  a  high  degree  of  versimilitude. 
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Ve  r.  ote  that  on-line  data  collection  and  analysis  routines  would  have 
more  general  applicability:  they  could  also  be  used  as  one  component 
of  embedded  training.  They  would  also  be  used  during  ongoing 
operations  to  provide  a  quantitative  basis  for  determining  when 
feedback  should  be  given  to  a  user.  (A  more  extensive  discussion  of 
the  requirements  of  in-line  "human  performance  monitoring*  may  be 
found  in  References  C  3  3  and  [43.  ) 

An  operational  testbed  could  be  effectively  constructed  from  nodes 
residing  at  different  geographic  locations.  Such  nodes  would  be 
linked  by  a  commercial  network;  data  transmission  rates  would  be  no 
worse  than  those  currently  anticipated  for  military  systems.  Such  a 
distributed  system  would  include  the  following  advantages  for  the 
design,  development,  and  evaluation  of  experimental  systems: 

(1)  no  single  laboratory  would  bear  the  burden  of  constructing  the 
entire  system,  yet  would  enjoy  the  benefits  of  evaluating  a  node 
within  a  larger  system  context, 

(2)  demonstration  of  the  system  would  be  possible  at  a  number  of 
locations  (thu3  reducing  travel  requirements), 

(3)  development  work  at  different  sites  would  be  available  to  all 
researchers  on  an  almost  instantaneous  basis,  which  would 
effectively  extend  the  research  community  of  all  groups  involved; 
sharing  of  resources  (e.g.,  technical  expertise,  software 
capabilities,  etc. )  and  critical  interchanges  would  be  a  continual 
process,  rather  than  events  that  take  place  only  occasionally  at 
technical  meetings,  and 

(4)  it  is  representative  of  the  real  situation  in  an  operational 
environment. 

Our  last  comment  is  concerned  with  the  tools  that  are  available  for 
prototyping  and  evaluating  human-machine  interface  designs.  Too  often 
the  majority  of  design  and  evaluation  time  is  spent  on  tasks  that  are 
irrelevant  to  the  i  ;sue3  at  hand:  hardware  interfacing  problems, 
device  drivers,  software  development  of  screen  formats,  etc. 
Consequently,  the  empirical  evaluation  of  design  alternatives  i3 
cursory,  at  best,  and  design  errors  become  apparent  when  it  is 
rxtremely  difficult,  time-consuming,  and  expensive  to  correct  them: 
that  is,  after  the  system  has  b:?n  developed  and  fielded. 

The  development  of  the  extensive  demonstration  described  in  this 
report  was  only  possible  through  the  use  of  a  very  high-level 
interactive  display  prototyping  language;  most  of  our  time  vs3  '-pant 
on  analyses  and  thinking  about  the  interaction  between  the  computer 
•and  the  human,  not  on  software  develop:.,  .-nt  or  hardware  concerns.  The 
demonstration  development  took  about  120  hours;  ve  think  ve  should  be 
hie  to  prototype  systems  even  faster  (e.g.,  reduce  the  120  hours  ve 
pent  to  about  40). 
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Such  rapid  development  i3  only  po.-'ible  if  ’rapid  prototyping"  tools 
are  available.  We  are  beginning  a  nuirber  efforts  to  develop  su:h 
tools.  One  tool  vould  accelerate  the  development  of  cinscle  "data", 
such  as  the  interactive  display  screens  described  in  Sectiin  3.0. 
Essentially,  tirr.e  would  be  saved  by  allowing  the  developer  to 
"program"  dir_otiy  in  interactive  graphic  ter:*3  --  e.  g.  ,  draw  things 
directly  cn  the  di-play  screen  --  rather  than  having  to  a.'tually  write 
software  cade.  This  tool  (an  exte-r.sion  and  enhancement  of  Ea  ?1,  the 
interactive  graphics  language  currently  in  use  in  our  laboratory) 
would  be  developed  in  a  way  that  gave  it  both  device  independence  and 
portability  to  different  operating  systems  (e.g.,  RSX,  VMS,  UNIX). 

The  end  result  would  be  that,  regardless  of  devices  or  computing 
environ;;: --nt,  a  single  high-level  development  "language"  could  be  uced 
to  develop  hunan-r  --chine  transactions.  Since  this  develop-ent  would 
be  so  swift,  alternative  protocols  could  be  prototyped  and  empirically 
evaluated  within  short  periods  of  time. 

Our  other  "r^pid  prototyping’  activities  address  the  data  development 
requirements  of  the  Generalized  Human-Machine  Interface,  a  system 
under  development  at  Lockheed  for  the  past  four  years.  A  description 
of  those  tools  can  be  found  in  two  proprietary  reports  (see  References 
[5]  and  [6]). 
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Appendix  7. 1 

Summary  of  HEL/AAAD  and  LEC  1-day  meeting:  7  December  1934 


Meeting  Date:  7  December  1934 

Location:  Lockheed  Electronics  Company,  Plainfield,  Lev  Jersey 

Purpose:  Show  Interactive  Protocols  demonstration  ar.d  hold 

discussions 


HEL/AAAD 

Lockheed 

Sgt.  Jim  Bevins 

Mr. 

Joseph  Barletta 

Dr.  Jon  Fallesen 

Mr. 

Richard  Brandau 

Major  Marcus  Cox 

Mr. 

James  Coburn 

Major  Roger  Duckworth 

Mr. 

Paul  Corrigan 

Major  Roger  Parks 

Mr. 

William  Guyton 

Mr.  Christopher  Smyth 

Ms. 

Merryll  Herman 

Mr. 

Jules  Kaplan 

Dr. 

Rita  Knox 

Mr. 

Don  Rowan 

Dr. 

Eric  Sigman 

Certain  revisions  were  requested  during  the  morning  demonstration 
cession.  The  revisions  were  the  changes  in  symbology  coding  described 
in  Section  3. 1  above.  These  revisions  were  incorporated  and 
demonstrated  in  the  afternoon.  Such  rapid  changes  are  made  possible 
by  the  high-level  development  tools  used  in  the  Human  Machine 
Interface  program. 

During  the  afternoon  session  the  following  issues  were  discussed: 


o  Symbology 


o  Primer 


o  Data 
Di  -up lay 


Should  users  be  able  to  specify  their  own, 
personalized  symbol  sets?  Should  one  standard 
symbology  set  be  used,  or  are  multiple  sets 
(differing  in  complexity  a3  a  function  of  the 
operation  in  which  they  are  used)  required? 

Embedded  training  is  a  requirement  of 

new  systems  under  development.  Operational  systems 

will  be  requiied  to  have  extensive  help  facilities. 

k'hen  should  different  data  be  displayed? 

How  and  when  will  data  be  selectively  filtered 
from  displays  as  a  function  of  the  current 
-activities  of  a  user? 

When  should  displayed  data  be  removed  from 

the  display?  Should  there  be  built  in  "time-out" 
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o  o 
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I 


I 

I 


o  Protocols 


o  Input 
Devices 


o  Who's  the 
User  ? 


functions?  Should  the  displayed  data  be  replaced  when 
updates  of  the  sane  type  are  received?  Should  the  user 
be  able  to  specify  that  he  wants  data  to  be  removed? 
How  does  he  accomplish  this? 

What  are  the  candidate  alternative  protocols? 

Can  they  be  compared  through  analysis?  Are 
demonstrations  necessary?  What  quantitative  data 
should  be  collected?  What  is  the  appropriate  context 
for  the  collection  of  the  data  (can  generalizations 
be  made  from  data  collected  during  half-hour 
experimental  sessions,  or  must  data  be  collected  in 
an  operational  context)? 

Does  the  separation  of  display  and  control  surfaces 
(such  as  is  found  when  information  is  displayed  on  a 
screen  and  inputs  are  entered  from  a  keyboard) 
impair  performance?  What  should  the  input  device  be 
(mouse,  joystick,  touch  screen  overlay,  etc. )  when 
display  and  control  surfaces  are  co-located? 

Will  the  Officer-in-Charge  (OIC)  ever  want 
to  directly  control  communications  (e. g.  , 
directly  interact  with  the  display  screen)  or  will 
communications  always  be  mediated  by  a  subordinate 
(an  operator  who  is  making  data  entries  based  on  the 
OIC's  directives)? 

What  is  the  appropriate  user  profile?  What  time  frame 
is  being  considered  for  implementation  of  new  systems? 
Will  fewer  individuals,  each  having  higher  averag 
capabilities  than  the  current  average  military 
personnel,  be  using  these  systems? 

Will  there  be  more  than  one  user  of  each  system? 

Will  individual  use  be  task-dependent  and  vary  as  a 
scenario  develops?  Should  the  system  be  adaptable  and 
modifiable  as  a  function  of  who  the  user  is? 


.  V* 
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r-i.-icjlicn  rf^i:en-‘.i  to  be  s-ppirted  by  the 
Generalized  Husan-Kach.ir.e  Ir.terfa :•  iGr.KI)  fall  into 
t«o  general  categories:  cc*  1  :«t  ion  :  r  tel  1  lcence. 
which  include,  isausption.  by  c:n  unicator., 
topical  context,  atyle,  and  versatility  of  inforaation 
representation.,  and  the  f.?Pif  lent  at  l  o-j.  thesselv#., 
f‘:ch  are  the  irfor»ation-to-dat.  and 
c  ita  -  to- 1  r.foreat  ion  trarelation  rule*.  Thl.  paper 
diar-aae.  the  representation  problexe  of  hutan-sachine 
c; iikr icat ion  elthin  the  context  of  acre  general 
feature,  of  hu»an  ccasunication. 

Introduction 

Interactive  ccasunication  Letveen  huean  and  aachine 
<i.e.,  coeputer)  ha.,  for  the  act  part,  been  eediated 
by  keyboard  and  display  screen:  the  user  Issue.  . 
atateeent  vhich  act  obey  the  rule.  of  so., 
well-defined  coaaand  language  and  the  eachine  answer, 
by  Sending  a  staterent  to  the  screen  and/or  by  changing 
soar  internal  state. 

An  alternative  approach,  vhich  allcve  huwan.  to 
cc”.n:at»  vith  ccaputer  systeee  in  auch  the  caae  way 
ae  they  cowwumcate  with  each  other,  i.  adopted  by  the 
Generalized  Huaan-Rachlne  Interface  progra.  (Knox  191). 
Suae  people  have  argued  that  an  lnter-huxan  rodel  »*y 
be  l  r  appr  opr  late  for  huaan-tachir.e  ccwaunicat  Ion.  They 
point  out,  for  exaaple,  that  there  Is  no  lnter-huaan 
exchange  that  1.  analcgou.  to  certain  graphic, 
c c * w and.,  or  the  wanlpulatlor..  of  graphic  syabole  on  a 
display  which  those  cowrrands  achieve. 

First,  our  use  of  "husar-huwan  ccwaunlcatlon*  at  . 
■  del  for  huaar.-wachlr.e  cm.-lcitlor.  1.  overly 
restrictive.  Hunan.  Interact  with  each  otter  and  with 
i  r r  :  wate  cbjects;  features  of  r  tnlpu  1  a  1 1  ng  iranlwate 
ot.  ».at  be  captured  In  huwir.-mohln# 
c  -  -  -  .o  i  cat  1  on.  The  concept  of  rotating  an  object  on  . 
sireen  is  net  foreign  to  huwan  being,  who  have  rotated 
real  object.  in  space  thousand,  (sillier, s?)  of  tire, 
during  their  lifetiw=..  The  appearance  of  rotating 
Oh. wet#  in  the  two  care#  le  different,  a.  are  the 
specific  acticr.s  taken  to  acccwplish  rotation  In  the 
two  worlde.  Central  iscue.  of  the  re;  rer ntatlon 
prrble.  are  (1)  how  different  the  visual  feature.  of 
the  two  evente  can  be  ar.d  still  retain  a  cor  re  or,  fence 
between  the  real  and  artificial  worlds  be  a ; , are nt  and 
(2>  what  should  be  the  relationship  between  sotor 
a  ot  i  _  e  to  wove  real  objects  .r.d  sotor  actio- a  to  sove 
artificial  objects. 

Second,  tho.jh  there  are  cc-puter -- .-diated  action#  for 
which  tiers  are  no  real-world  aralog.ee  (eg., 

•  an: - u I  at  1 c: #  that  violate  the  laws  of  ph.F-.c).  dee. 


m  l  -  c  1  •  *  -1  E  -  :! < 


this  sea.n  that  the  rulea  cf  real  w'r.d  inter  act  a  are 
irrelevant  to  humn-ccsputer  interaction? 

Third,  there  are  feature#  of  irter-h  .ran  cm  mint  ion, 
euch  a.  our  ability  to  follow  an.itlo.*..  between 
topic.,  which  .r*  not  generally  available  in 
huwan-aachine  cowsunicatlon  (Ean.non,  et  *1.(11);  their 
absence  liait.  huaan  exploitation  of  ccwputer 
capabilities.  The..  features,  such  a.  huwan 
attentior.al  abilities,  are  overlocxed  when  crlticisa. 
of  the  inter-husin  aodel  of  huaan- a. chine  interaction 


Increasing  esphasl.  1.  being  placed 
of  natural  language  processing  i 
co w runl cat i on  (are  Strategic  Coaputir 
agree  that  natural  language  1.  an  is; 
it  i.  only  one  vehicle  of  inter-h. 
If  and  when  full  natural  la.ngua; 
wachir.e.  i.  achieved,  it  will  not  eud 
of  expression  for  all  ideas  we  sight 
with  aachine*. 


on  the  importance 
or  husan- wachlne 
g  (143).  While  we 
ertant  capability, 
san  cowsunicatlon. 
e  processing  by 
flee  a.  the  wedlu. 
want  to  exchange 


When  people  cexaunlcate,  they  eele 
not  necessarily  with  any  awarer.e 
cot wunlcatlon  tool,  th.t  .re  ap 
Inforaation  being  cossunlcated  and 
constraint,  of  the  coaaunlc.tlon  env 
listen,  write,  dr.w,  geeture,  p 
ewphasls,  and  so  on,  a.  the 
cowsunicatlon  event  varrant  and  allc 
1.  a  relationship  between  the 
corsunlcated  and  the  way.  it  ca 
woreover,  the  circua.tancee  governir 
say  lwpose  llsit.  on  the  variety 
that  will  prove  useful.  For  ex 
gesturing  are  useful  in  direct  CDtsu 
ii. effective  during  a  phor.e  cor.veruat 


ct  and  uae  (albeit, 
is)  an  array  of 
p.-epriate  for  the 
.eeable  under  the 
ironaent.  We  talk, 
oint,  add  vocal 
condition,  of  the 
w.  Th.t  Is,  there 
i-forsatlon  to  be 
r  be  represented; 
g  the  cowsunicatlon 
cf  representation# 
isple,  drawing  and 
-  i cat  ion,  but  are 


To  erploy  the  tool,  of  huwar.  ccr  tun  l  c  at :  on  in 
h.-an-wuchine  cowsunicatlon  we  understand  how 

hu'ins  sap  t a ck- rel ev ant  lnfor-ation  Into  Cat. 
:  epreaentatior..,  such  a.  sentences.  pictures,  and 
g  etures.  Although  we  are  pri»a-:Iy  concerned  here 
with  the  repre'  :  n tat : on  probles,  we  c.rorot  Ct  al  with  it 
independently  of  other  huwan  information  proceeBing 
cipabi 1 itie.. 


Runy  researcher.  are  studying 
huwan- rachine  interface  (HNI. 
•ean-waohlne  interface,*  "user-cos; 
etc.).  We  note  here  that  in  scat  c 
Inquiry  la  narrower  than  oure  In  that 
huwar, -wachlne  Interface  extends 
representation  probles.  Since 
add: eased  the  probles  within  the  co 
for  the  developxent  of  the  GKRI, 
between  their  definition  of  pro'occ. 
is  rot  clrar  cut.  We  will  at’, 
d  .crlbe  the  relationship  bct.tr  - 


the  pr'hlea  of 
and,  variously, 
.ter  1 r ter  1  ace,  * 
ps  the  dc«ain  of 
the  definition  of 
- ly  to  the  data 
•  here  have  not 
text  we  have  uoed 
e  corn  spender, c* 
fo  atu.-is  and  Core 
•pt,  hewever,  to 
. :  »  or k  and  ot ht  r  p 


'  -  n  !  x  1 5  rj 
■  n  h  „  '  , :  a 


• w  1  1  1  *  i  s-  • 


■  y 


v  n ;  v  e  a  *  .  *  ' 
* »  ,  :  <  ♦  at  on  of  tb 

a  t :  ,  t  •  r  1  .  i  . a  : 


in  :  ‘  ;  .g  a .  •  r  y  for  ir. f  -.  r  «  « t  icn  x  h  i  ch  1*  relevant 
to  t  ‘  *  :  :  •-  t»s«  of  t  h «  c.;r»r.t  t  c  p  1  c , 


a  a  ■  1 1  a  -  a 


taring  that  lrfcrsatlcn  1(  Biasing, 


aeiectlng  ;  or  dy-aabrally  building  -  n«  Chafe  CS1) 
the  idea-path  through  th#  larger  #t  or*  of 
■  •  r  >  -  r  r  1 1  der.t  i r. f  cr  aat  lor.  II.*.,  itiir.'.lc  aeaory, 
a;  -  lie  -  :jry  -  »**  ■'jay  and  Korean  1101, 

*  .  •  ,  -  h  r  ~ ’  1  •  *  1  y  i  ••.Ob  » *.  1 1  Is  *»  rt*a  .-d 

tc  ..»«. •:.»!*  ir  ft  .-tat:  on,  cr  •  th--.hI  for 
:  r  f  .■  ;cn, 


:  t‘e  t,.q..-.;e  in  »h ;ch  If*  id’ a  a  »r*  to  b* 

>■  d .  in;  f  : '  a  1 1  y 


c.b.fyir.g  th*  idea*  in  a  for*  »hich  can  b* 
c-_  »i  ,p :  :»ted,  and  then  externalizing  tie*  <1.*., 
r s a ,  is  ; ?  er at l on ) . 


Ar  i  ,s'.n»  Sitting  of  hsun  rep  i  •  -  c  r.t  at  ion  pheroaina 
i*  not  p.eeibl#  her*.  Hoiever,  there  ar*  certain 
cilie.it  Cj,  lillltiei  that  hav*  been  cor.»lder*d  in  th# 
CeB.rn  ;f  the  G K R 1 . 


the  E«i*  (or  a'.allar)  avanlng  1#  captured  by 
different  physical  representation#.  Ccnalder,  for 
e-.aple,  the  varlou*  external  fora#  that  can  be 
.i"r.»t-d  by  the  concept  of  a  "roe*.  * 


i'ile  <e  hav#  the  ability  to  extract  a  ccaaon 
r  -.-ept  frea  different  external  repree entatlon#,  «■ 
do  not  d'.acard  th*  aodallty-  or 

:  epn  aentat  Icn-speciflc  lnfor*ation  about  hoe  the 
c:  crept  »•*  c;x«  jr.lcated.  That  la,  w#  ar#  capable 
of  res  «berlng  th#  particular#  of  hoe  e#  learned  a 
particular  plec#  of  lnfor»»tlon.  If  aaked  hoe  you 
kr?»  hoe  to  get  eoaeplace,  you  eould  probably 
iter  If  you  had  teen  given  Instruction#  on  th# 
p'  o- e  or  If  aca-on#  had  dravn  you  a  aap. 


T.riiliy  equivalent  r  epr  ee.r  t  at  lor.#  do  not 
urliy  convey  the  Fixe  *:>nlng,  a#  aany  of  u# 
.ruiire  then  lcr'xlr.g  at  an  equation  a#  opposed  to 
!•  V:r  j  at  a  graph  of  the  ease  equation. 


rr.ect#  lor  e>'<nt#t  have  aultl-aodal 
.‘.pi  A  rr. /e  haa  color,  for*.  erent,  axuOth 
■  -rp  t“»*.  .rea;  a  auving  autcaobll#  has 
<‘-i  a.fitory  md  visual  feature*  xb.tch  change 


.  «e. 


If  >(  are  to  Incorporate  these  huaar.  representation 
-x;  ‘llillee  in  a  huaar  -  aaohlr.e  Interface  cur  design 
’  .  b  t  •  ft  at  luatl  the  f  o  1 1  o « 1  r.  g  req,ireus-nt#i 


f’e  i-pt  of  dlff"rent  r t  pr .  urtit at  1  one  for  th* 

!  r  f  :  -  f  :  xat  1  on  a  at  be  pr 1  sent.  A  eaepl*  of 
;  1  h  .*  alter-  atlve  repreu  r.tatlon#  le  presented 

in  n ;  .re  1.  The  interface  >jit  be  capable  of 
;  r-.-atln;  alter- atlve  r eprenent a 1 1  on*  for  output 
to  tie  ‘..m,  and  of  rt  during  different,  but 

•  j  :  •  a  1  c-nt  data  Input#  to  the  sat*  Internal 
i  f  -at  .on.  Ideally,  the  cr.e-to-aany  and 

•  ■ f  t  c -  one  aapping#  vould  be  epeclfled 

a  1  g;  - :  • ‘  a i  ;*  1  ly.  At  leaet  for  th*  present, 
h. never,  the  various  r  epr  ■ -■  e  r.t  at  len#  *111  be 
o  f :  -  ‘  d  or,  a  can-by-css*  t  el*  el-c*  a  general 
a  1 5  .  - :  t  ‘  *  i  c  d*  . rip  t  Ion  re;  ilrsi  an  understanding 
o  !  r  •  a  r.  .  t  t  a  1 1  o  n  .  xp-itli’be#  v  hi  ;  h  1  ■ 


c,i  n-r.tly  uravallxtle.  (In  fart.  it  :  e  .r,  x  e  * 
ttst  le  In  r.e.-d  of  r  ireh.  » 


Fig. re  1 

hultlecdal  attribute*  of  a  particular  c.vrt  •r.;,.d 
be  captured.  For  exaaple,  it  alr.  d  re  p:„sible 
for  eoaeon*  to  eay  •Rove  thi#  or,*"  a  1  hi'.*  tr* 

aachlne  underetar.d  that  th*  object  ;:*  1*  pointing 
at  i#  th*  referent  of  ’this*  (see  ?;;*ardt  ar.d 
Hulteen,  1121). 

*  Th*  interface  auet  deteraln*  »h.i;h_  of  the 

repreaentation#  for  aoa*  inforiatlc-  a ■  -..i  be  ujed 
at  any  particular  tla*.  V*  don't  t.-x  *e  choice* 
are  arbitrary,  but  depend  on  a  r.ua.  er  of  thin;*. 
First,  <hil#  aor#  than  on*  reprrr  , ->t  ation  can  be 
uaed,  •  particular  rapreaentatlon  n.  be  the  acre 
natural  choice  for  certain  lnforaa' bon.  Roreover, 
the  repreeentatlon  selected  aay  ;cfsnd  on  th* 
particular  user)  so  the  syetea  a. at  *\‘i  ihat  the 
relevant  user  attribute*  are  in  deter ai-g  th*  use 
of  a  particular  representation.  Second. 
Input/output  d.#. ,  huean/coaputer l  representation# 
during  a  particular  task  should  be  "vatched.*  For 
cxaapl#,  »hll»  it  alght  be  poeelble  to  ccaaur.icete 
certain  lnforaatlon  either  by  talking  or  by 
•  rltlng,  it  «ould  be  a  peculiar  ;  :  r.  .tr  ^  at  Ion  in 
vhlch  one  party  talked  and  th*  other  party  irot*. 

Relevant  GHHI  Coego nent# 

Th#  GHHI  syste#  under  develop »ent  eupport# 

huaan-aaohln#  coaeunlcetlon  by  perforaing  natural 
language  proceealng.  at  tegt  l_on  aor.ltor  :  ng  to  provide 
context  and  sequencing  to  uaer  lnpute  and  eventually 
host  or  external  Input#),  dynaelc  devlc  -  aBslgriaent  to 
reconflgur#  th#  u##  of  conaol#  device#  In  near 
real-tla#,  and  huaan  perf oraance  aorilt ;•  b nfl  to  detect, 
cstegorlz#,  analyze,  and  provide  ft  brack  on  user 
error#.  The  tra.reiatlun  betieen  devl  r  ;  -  ep  pci  f  1  c  data 
and  internal  GHRI  representations  11  perforaed  by 
d* cgde  and  encode  eodule*  of  the  a  ete*.  A  data 

*  ,r  a;eaent  structure  l  see  Brandau  and  h  ;x  '.3)1  allcvs. 

a  ng  other  thing*,  the  entry  of  user  -  d  »  '  .  r,  nd  ec.-aard# 
to  off-load  data  aonltorlng  and  aer.tal  -  l ■  j  1  at  1  on#  to 
the  aschln#.  All  appl  1  cat  1  on  -  apecl  f  l  c  ‘it*  ur  =*d  by  the 
C-.RI  aystea  la  represented  entirely  aa  dv‘.a;  thi# 
allcva  ne»  application*  to  be  develcpvd  th-o„gh  the 
authoring  of  data  tibiae,  and  vithou*.  •  l’f:r»tion  of 
proceaaing  cod#.  A  dlagra*  of  the  a,a‘.=  *  •> :  ch  1 1  ert  u:  e 

appear#  In  Figure  2. 

In  the  GHHI,  protocol  and  repree.--r.tatb  a  are  pcvi-jr.ed 
by  the  Decode  aodul#  lof  ihich  Ha  ral  La  j.age 
Processing  1#  ■  part),  the  Encode  »  du.i.  the  Attention 
Hor.ltor,  and  the  Dynaelc  Device  Assign*  -t  ■  dule. 

Decode  accept#  sn  input  fro#  the  uaer.  m.  ,a  «>ay 
device- apecl  f  lc  lnforaatlon,  convert*  -•*  »‘.i'  .  ent  to 

*  standard  internal  for*at,  and  pap.-.v*  e  c  ■  ,nd  to 

the  Attention  *cnitor.  Thi*  »:bjle  -•:»■*  .  ;h 

t-.pic  th#  •obj'Ct’  cf  the  co»*i-d  ,s  to  A 


Figure  2 


’topic'  :■  defined  *  collection  of  tasks  that  can  be 
per for sed  on  object*.  Topic  Identification  require* 
t’at  thing*  irt  talked  about  In  a  particular  soquencs. 
iTr.a  a  -quen 1 1  al  cor.atraint*  that  ar*  actlv*  at  ar.y  tla* 
are  path-dependent  and,  aay,  in  fact,  epscify  that  any 
n.sber  of  object*  aay  ba  talked  about  In  any  order.  ) 
If  the  object  of  th*  coaaand  1*  part  of  an  actlv* 
t -  pic,  the  topic  Identifier  1*  appended  to  th*  coaaand 
Mori  It  l*  paased  to  the  Data  Baa*  Interpreter  for 
execution.  If  th*  object  1*  part  of  a  nev  or  deferred 
topic,  continued  convereatlon  vlll  only  be  possible  if 
the  topic  can  b*  ( re  I  activated.  Thl*  depend*  on  • 
determination  by  th*  Dynamic  Device  Assignment  aodul* 
as  tc  vhether  or  not  virtual  device*  <s.g.,  different 
q.Mrar.ta  of  a  display!  required  by  the  topic  can  b* 
•:e  available.  Briefly,  the  decision  depends  on  th* 
currently  actlv*  topic*,  th*lr  priorities,  th*  virtual 
devices  In  use,  alternative  virtual  device*  that  aay  b* 
-a.-d  by  each  of  the  topic*,  and  th*  ’disruption*  vhlch 

■  ay  be  oa-eed  by  reassigning  setiv*  topics  to  r.ev 

,  .a,  devices,  and,  ec  net  1  rev  representations. 

T • »  point  here  Is  that  the  activation  of  s 

•  ;;c  and  the  r  --pr  pi  er.t  at  i on  of  the  1  r,f or  aat  1  on  of  that 

•  ::z  •■•;,'td  or.  t!.e  order  In  vhich  preceding  t  plc* 

•  e  activated,  and  on  the  particular  array  of 

t  :ca  tc  vhich  a  rev  topic  aay  be  added,  as  veil  as  on 
rent  properties  of  the  topic  itself. 

If  the  topic  su:  -«.-->ds  lr.  being  activated,  the  virtual 
■ :  :i  s"  i  jr  at  r.  t  Information  and  activation  'trigger' 
are  lapsed  to  the  F need*  acdul*.  All  sub  r-quent 
hr-  ..'ir.*  on  this  topic  are  vediated  by  the 

:  i:  titular  data  r  e  pr  e',er.t  at  ions  defined  and  processed 
ty  •  ' »  de  a-.d  F---.de  modules. 

Irterartive  Frctocol  !'*..es 

In  >h  a  eec’lon  ve  de-  -rite  a  fev  machine 

.•t-ire.  rt  at  ion  fiatures  that  have  been  proposed  by 
■ere,  a-d  diBCua*  th“ir  aerlt*  in  tern*  of  the 

■  .  -a  vade  lr.  the  d  *  s  i  g  r  of  the  Fr'*I. 


A  sajor  advance  In  husa.-,- machine  cci  ’ ication  «a*  the 
development  of  the  multiple  vindov  ic.rept;  it  allova 
the  material  for  a  nusber  of  urer -act ; vated  ta-Vs  tc  be 
simultaneously  presented  on  a  display.  Tv  e  Ha.  naicn* 
of  vindov#  say  b*  u.-er-deflned  a-d  the  vmueva 

thereelves  say  b#  ’stacked.’  While  the  ability  to 
Pl  aultareously  dlBnlty  and  acceBB  sul’.iple  is  a 

f-.  ature  of  the  GKHI,  the  overlapping  of  t-  k-vindcva  1# 
deliberately  prevented  for  e  nosier  of  rev -ora.  First, 
the  GKHI  le  a  sedlator  betveen  tyc  pant  it  s  (as  hcvn  In 
Figure  3-e).  Trsdltfonsl  ’vlndoving*  gives  control  of 
the  display,  and,  hencs,  th#  toclce  cf  ccr.ver:  atlon,  to 
one  party  of  the  conversstlonel  dyad:  the  huuan  sitting 
#t  the  console.  If  the  human  and  aac-ln#  (or  hu<an  and 
h-.-aji  if  the  ’aachlne*  Is  a  ccsputer  -  s  „»  in  i  ed  retvork 
of  husansl  are  engaged  In  vork  vh> re  tvey  have 

complementary  assignments,  there  cc.ld  be  u-riou# 

consequence#  If  the  machine's  prior.* its  are  not  given 
consideration  In  the  configuration  cf  topic#  on  the 

display.  Consider,  for  e>.a-ple.  the  situation 
illustrated  In  Figure  3-b.  P  :  ar  *  .  r  i ;  ■>  nt )  1  ’  s  topic 

priority  ordc-rlng  Is  a-b-c-d;  P2  e  is  c-b  a-d.  If 

vl  r.  dees  are  arranged  a:  rcrdlrg  to  PI 'tf-.'-’r--  P2 

vlll  not  be  able  to  - .  meat  e  it  :  t  e  h.  .'  at 

p-lority  topic  -  c;  If  per  f  cr  *  a.nce  cl  a  ..  a  d  r  ■  de 
cn  both  participant’#  vork.  vc  v  -  .  .  ;  •  ■  ct  it  to  be 
r  piously  1-p aired  by  Pi’s  ic  e  cf  F2’s 

lr  for  a  it l on.  tin  otter  v.n.ds,  P2  .-  • i  •  o-l  y  .  tiring 

or,  tcplc-c  and  the  data  on  the  *  lc-c  v.rdov  le 

charging;  hcvever.  If  the  vlrdcvs  a  -  =  a.  - d  tc  FI's 

ordering  he  vlll  be  u-a.a.-e  cf  P2 ’#  ;  '•».  I 

Si  sor.d,  even  if  the  GKHI  is  aydiatir  g  .  •  r.  .  r,  a  k  .van 

ar.d  a  B/ete#  ’slaved’  to  that  h.  .  'e  ■  "a,  the 

tradition*,  vindcvlng  approach  p  ut#  •  -  h  ,.  bn  or.  the 

hu-an  to  lesrnber  vhere  topic a.»  1  :„'.vd  (just 
is  he  or  the  must  search  for  or  ■'  t-r  :  e  an 

1-portant  slip  of  pa;  er  h  -.#  v  r.  -  .  1  .r  a  r.  *  a  ;  k ) . 

Tnlrd,  the  vork  to  rearrange  th.e  tep.c  .  jts  to  bring 

there  of  current  lr.te.--et  to  ‘he  "tup* 
l  ’  r  eco- f  igui ..  t  lor.  ’  >  a  .at  le  ; 
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c  r  1  «r  p  ir.g  wi.dtwm  *r*  allowed  ir.  the  G.-.*I 
r  ■  -:t‘;r.g  tbe  use  o  i  ever  1 a;  p  i  ng 

:»9;  '.'ey  •'-•ply  ire  r.ot  cefired  In  the  C;."a»lc 
:»  i  wnl  ^i‘i  table*).  The  work  of  detecting 

u'.i  fer  or  inferring  the  currently  pertinent 
re,  presenting  the  car  re  i; ending  display-control 
:«b,  »-  i  »rt  i  vi  1 1  r  g  's  .spending  tcpicm  n  r.ececea  ry 

carried  out  by  the  Attention  Kopitor  and  Dyr.aeic 
ae  »fi:;nrnt  modules.  w*  hive  anticljated  the 
not  yet  implemented  e  facility  that 
h.nn  to  override  tht  ae  module*' 
ell,  since  huaar.m  can  isVe  errora  in 
d/raalc  prlorltlea,  the  GKHI  can  be 
cted  to  mike  alotikea,  too.  Hciever,  the  benefit* 
having  the  computer  take  cmre  of  the 
i r ; at r it  1 ve*  detalla  of  keeping  lnforaatlon  it  the 
'a  firgertipa  outveigh  the  occasional  delaya  that 
be  introduced  vhen  the  user  euet  repeat  (or 
icitly  atate)  that  a  particular  topic  la  required 
llately. 
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w?at  commonly  uced  forme  of  husar.-ccaputer 
pr.tcccle  have  been  menu-eelection,  f  cr  a-fi  1 1  lng, 
z. d  language*.  and,  more  recently,  limited 
•natural*  itnguage.  Clearly,  thie  ie  not  a  co-plet* 
list  of  cptione.  for  ex?. -pie,  up--cifying  a  point  cn  a 
display  screen  la  neither  fcra-fllllng  nor  natural 
ia.-g.aje,  although  graphic  manipulations  may  te  similar 
to  ratural  language  In  certain  formal  respect*.  We 


tnu -selection. 


vculd  also  argue  that  It  le  r.ot  • 
although  it  could  be  formalized  ae  ■ 
pi»ele*  operation.  r.wcver,  even 
r i  J ■  1 . *.  1  c n  display*  It  Is  d c u b t f u  1  that  the  o u v a n 
~.r  ept-ailze*  the  problem  a*  a  »  -.  u  -  c  e!  ect  1  on 
c;  .-rat  i  on. 
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example,  tie  response  set  for  an  e-try  may  te  too  large 
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r.l'ply  ditermlrid  by  hom  the  u>-er  »iy  enter  c.ita  to  the 
.*T,  but  moot  also  c  _  ldt-r  ‘cm  the  r  r 

j  .1  ^  ‘.a  to  t‘ •?  4  u-.cn.  Even  mh-.--  *  re  t‘  .n  e 

r  e  p .  . t  o.col  le  logically  ft 4  .bl e,  It  ■  ly  4  e 

d  i.-able  l  ».  g.  ,  to  a.r.lml  ie  e.icril  tc  allow  only  -  j? 
protocol  type  to  be  ur-t-d;  for  example.  to  nq.i.e  f.e 
explicit  rc..  ot.ee  to  be  selected  free  a  »el  1  -  c«f  i  r.ed 
rt-speroe  set. 

Even  a*  the  set  of  different  protocols  for 
t.  .man- lachl r e  inter  ction*  grern*,  acme  b?9ic  problem* 
remain  to  te  studied! 

What  ie  the  relationship  between  the  fata  req.ired 
from  the  h.var,  or  machine  a  d  the  protocol  to  te 
used? 

What  le  the  relationship  tetveen  a  display  format, 
for  example,  ar.d  the  Implied  prctcrcl  to  be  used? 

What  are  the  behavioral  and  operational  condition* 
mhlch  suggest  mhen  there  should  be  many  or  few 
protocol*  for  the  user  to  chocae  from! 

Interactive  tarjuagem 

There  ham  teen  much  recent  mork  on  the  vBe  of  formal 
grammars  a*  the  mpecif ication  language  for  the 
protocol*  of  human-machine  interface  (ReiBner  [121; 
Jacob  (71;  Eisner  and  Foley  (21),  and  discussion*  of 
the  relative  merit  of  different,  but  formally 
equivalent  representation*  (Jacob  161). 

R.-ianer  ham  argued  for  and  demonstrated  the  predictive 
importance  of  specifying  the  cocr : tlve  operation* 
(e.g.,  »: very  search)  along  mith  the  cbeervable  action* 
(e.g.,  button  pressem)  required  to  perform  some 
function.  Thi*  modelling  of  cognitive  operation*  in 
the  analyst*  of  human-computer  interaction  has  teen 
developed  tore  fully  and  described  by  Card,  et  ml. 
[41;  their  'Hodel  Human  Processor’  is  defined  by 
para-eters  of  human  information  processing  mhich  have 
teen  discovered  through  basic  research.  These  model* 
are  extremely  useful  in  assessing  alternative  protocol 
design*  for  veil  defined  task*  such  am  text - edi ting; 
however,  they  do  not  capture  many  human  capabilities 
d.L-crited  in  the  preceding  section*. 

Formal  description*  of  the  4 user-cc vputer  interface' 
have  included  the  specification  of  semantic,  syntactic, 
and  lexical  level*. 

The  semantic  level  ojociflt-m  the  actic-s  to  be  executed 
by  the  co-puter  upon  receipt  of  particular  cci-ands. 
l: fep : nf.nt  of  the  for*  in  which  the  commands  were 
i r.  - u ?  d  t y  the  u.  vr. 

T;  "  syntactic  iavel  ducrilca  sequential  constraints  on 
••r.rda*  (or  tokens)  which,  when  satisfied,  uniquely 
d  fine  •  u/utem  action.  Tt.e  idea  is  that  a  ’word’  can 
)a.e  wire  than  cr.e  interpretation  bated  on  the  context 
in  which  it  »rp-  ar*;  moreover,  a  sequence  of  w-.-dm  (a 
* r.t ,  r. ce • )  may  have  an  Interpretation  h  oed  on 
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formal  t  fi .  at  1  on  vithin  the  context  of  GEM  m-at 
:  ’’.re  ill  i  rep -as  ■  r.tatirn*  fur  the 

'  4  t  -  r  t 1  rtj  l  ^r  tack.  Thu,  in  i'.ra.f, 

,  ■  r  t  ;  „-nt  sorir-a  probl-ra*  for  th:  -  formal 
;  Tre  difficulty  ar;>f«  in  specifying  tk  e 

c  ditiore  for  the  «?l*:tlcn  cf  »  particular  protocol 
•  ith  i  particular  rep.eo:  txticn.  The  state  upon  vhich 
fe  select  ir*.  depends  ■  at  include  oth  =  r  ectlve  task# 
a  c  t'-e  r>r.-; .  cr.tatto- ■  (hr.-ce,  the  virtual  devicejl 
fey  use.  Tr.ii  configuration  of  active  tasks  depend*, 
ir.  turn,  on  the  sequence  in  vhlch  the  tack;*  ver* 
activated,  their  priorltie*,  the  array  of 
rep.e -sntatior*  available  to  each  of  the  task*,  and 
conflict*  betveen  tasks  for  the  particular  device* 
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•novice"  «-f  ’expert'),  : -t  will  provide  a  dyr.aaic 
u.tSLijnt  of  a  u.er'*  p..for*ince  at  a  particular  ti«e 
or.  a  farticula r  day.  These  state*  are  considerably 
tore  complex  than  those  f  eemted  by  previoue  research. 
At  th.la  point  is  do  not  krov  if  foraal  graaiar*  are 
appropriate  predictive,  analytic,  or  descriptive  tool* 
for  repree.rting  the  C.-1RI  syste*. 

Fecrese.-t* tiers  at.  the  Interface 


for  the  calculation  to  be  ex-o.ted.  A*:-r.g  the 
alternative  tyutix  a  that  cc-ld  be  foil-*  d  are: 

(1)  The  veer  »•  at  r?le;t  coe  cp  filer  fo!  Iced  *.y  ore 
operand  and  the  sentence  is  c.  i:  lete  'n. 
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In  thi*  section  ve  briefly  describe  sc*e  of  the 
prrbleas  to  be  solved  in  the  explicit  representation  of 
i r.f  or  «at  ion.  We  vlll  restrict  thi*  discussion  to 
interactive  display  screens;  a  more  general  treatment 
vould  include  such  thing*  a*  keyboard  and  voice  entry 
and  voice  response.  Ve  vlll  not  be  concerned  here  vith 
specific  device  technologies. 


ia) 

Hi),  glx) 

1  CCMPl' 

i  x  s  L'SIA'rCt 

fPOM ; 

.  .Ship 

ID) 

fix).  Ily),  III) 

9  PRCJEC 

•  i  s  "CSiTlON 

IS  Five 

"  S^TES 

lei 

llgtxl) 

Figure  5 


It  has  been  argued  that  ecftvare  programmable  control* 
r  huuld  ioth  lock  sr.d  be  operable  like  the  hard-control 
:  cur.terp  =r  t*  they  are  replacing  (Kakatanl  and  Rohrlich 
till).  The  lleltatlon  to  this  approach  1*  that  there 
are  aar.y  r.?v  processes  that  have  no  hard-control 
p.-edeceF.uors;  It  1*  not  clear  that  an  Interactive 
language  designed  to  accommodate  all  dialogue*  vithin  • 
r.ev  syste*  vlll  allov  the  incorporation  of  the 
h.ard-cor.trol  analogues. 

The  data  on  an  interactive  display  screen  li.e.,  one 
that  a-.-diates  both  display  and  ccntiol  functions)  *ust 
not  only  convey  the  information  of  a  topic,  but  *u»t 
also  ccvsjr.icate  protocol  rule*  and  the  current  »tate 
cf  the  syste*. 

rur  axa-p'.e,  in  the  ~r.Hl  ve  use  the  convention  that 
.  1 1'  gular  labelled  key*  r.-diate  on-off  (more 
_  rally,  binary  state)  f-rotiors,  and  this  coding  i* 
■d  u-  rtly  <c.?  Sii-aer  a-d  Foley  12);  Kakatanl 

.nd  r-rrl.oh  (111).  We  originally  ceded  the  eff-state 
o  a  -f‘ed  line,  the  cr.-state  a*  a  eolld  line  (see 
r.  p.re  4-a).  A*  it  turned  cut,  the  tvo  state*  vere  not 
ff'.oie  tly  distinctive.  We  have  since  changed  the 
'  .‘e  ird:  cation  tc  that  ehovn  in  rig^re  4-b:  the 
■rtate  is  drffintiited  fro*  the  eff-state  by  the 
.-Id:  tier,  cf  a  solid  bar  across  the  top  of  the  key.  So, 
tie  on-off  function  is  implied  by  the  shape  of  the  key, 
-i-d  its  state  is  indicated  by  the  presence  or  absence 
.  f  a  tar. 

7‘e  b >n y -  state  key  exarple  1*  fairly  simple. 

tder  the  furcticr.al  properties  of  the  operation 
:  1 1  .  - ‘ r a  t  e  d  in  Figure  5 .  1 ■ r  e  v  e  have  a  data 

:•  Id  elation  teak  vhere  a  u-  -r  a  ay  r.q.vat  the  distance 
tntxeer.  e*’  object  <e.  g.  ,  a  target  or  land  isvll  and 
v  i  s  *.t  crip’  f;  ,-ator  "f’l  »  d/or  the  projected 
.it  in'-.  4  »  |f  reject  lr.  five  *ir  jtre  <t;  -rator  *g*). 

T  ■  *  -  :  a  .  *  t  up  ••cl  f  y  tnth  f  e  .rater  .nd  the  op  rand 


(2)  The  user  *ust  select  one  operator  folloved  by  one 
or  »ore  operand*.  The  sentence  1*  complete  vhen 
operand  selection  ie  ended  (b>. 

(3)  The  user  may  select  one  or  more  operator*  before 
selecting  •  single  operand.  T.te  interpretation  of 
successive,  contiguous  selection  of  operators  is  a 
composition  function  (c). 

(4)  The  user  *»y  select  one  or  more  operators  (a*  in  3) 
folloved  by  one  or  more  operand*  la*  in  2).  The 
interpretation  is  a  composition  function  applied  to 
multiple  objects  (case  not  shevn). 

The  calculated  result*  of  the  four  syntaxes  mill  be 
different  (provided,  of  course,  that  multiple  operators 
and/or  operand#  are  chosen  vher.  the  option  :  s 
available).  Assume  they  are  ail  meaningful  to  some 
syste*.  Do  ve  design  the  task  and  the  display  screen 
to  allov  any  of  the  four  syntactical  structures  to  be 
u_?d  (a#  opposed  to  designing  four  tc-parate  t^eks,  each 
corresponding  to  one  of  the  syntaxes)?  Hov  are  the 
syntactical  constraints  made  apparent  in  the  visual 
f.oture*  of  the  interactive  display? 

S.ppose  ve  have  designed  a  ta?v  using  the  e.rpiest 
syntax:  one  operator  folloved  by  c?  operand  II).  In 
the  example  ahovn  in  Figure  6-a,  ’-ELF*  and  ’ c EAD-OUT’ 
are  operator*,  ’A,’  ’B,  •  ’C,  *  and  ’D*  are  op-rands. 
Operator*  are  coded  as  circle*.  The  user  decidua  to 
*Ek  for  help  <i.*.,  ’pick*’  the  HE-5  key);  this  move* 
the  task  Into  the  state  vhere  an  c;- rator  is  active  and 
an  operand  must  be  selected. 

In  Figure  6-b,  the  folloving  state  information  is 
present: 

’HELP*  is  active  (indicated  by  the  filled  eq.a.-p  to 
the  lover  right  cf  *  he  key). 


.  .  3 


□ 

□ 

□ 

□ 

© 

© 

(a) 

□ 

R 

□ 

N 

(m 

© 

(b) 

□ 

□ 

□ 

□ 

© 

(  HfLPj 
(c) 

Figure  6 


Pef  crrices 


[13  E'-nan,  L. ,  Cypher,  A.,  Grefg, 
K.L.  Eilvatlon  and  -n-ilyo-ns  cf 
c.-„  ri  :«t Ion.  In  Pi  qs  ChX'f3 
C  r  :r a.  Syeten  IB:  ton.  12-15 
AIK.  Sc»  York,  pp.  54-57. 


"7  " 

’  •--y 

1  F.  -;‘.vs.  i  n 

car  1 o-3 )7 


(23  BIreer,  T.  and  Foley,  J.  D.  Tcvarf*  Ep;  nfyir  g  »r.d 
evaluating  the  huxan  f-ctors  si  user- o;  tputer 
interface!.  In  Proe  CKI_L.82  H.a  :n  F  a  c*.  ore  In 
Cc  noting  Srsteas  (Gaithersburg,  15-17  Parch 
1952),  pp.  359-314. 


(33  S.-ardau.  R.  ar.d  Knox,  R.  E.  •Cj.-.-er.f :  A  dyrraic 
- pr-reclpic.-.t  object  base  for  tactical 

h_  ur.-iiohire  transactions.  Ir.  P  .-  :  r  ■  7th_  "IT/I-R 

Verve) op  on  C"3  Systera  (San  Piece,  11-15  June 
1534). 


[43  Card,  S.  K. ,  Koran,  T.  P. ,  and  hr, ell,  A.  The 

Psvcholocv  of  Hunan-Coaputer  Infers  :t  ion.  La » r er.ee 
Erlbaua  Associate!,  Hillsdale,  Kev  Jersey,  1333. 


(33  Chafe,  V.  L.  Creativity  in  verbal  ceatien  ar.d  its 
irplioatio.-.a  for  the  nature  of  stored  kncvledge. 
In  R.O.  Frtedle  (Ed.)  Pi scr-rse  rrcdvctijc n  and 
Cerprehenaion  Voluee  X-  Kev  Jersey:  Ablex 

Publishing  Corporation,  1977,  pp.  41-53. 

(63  Jacob,  R. J. K.  UBing  foreal  speci f i eat  ions  in  the 
d.sign  of  a  huaan-cosputer  interface.  In  Proc 
CHI  *82  Hunan  Factors  in  Co  -  -  utirvg  9 y  at ?_»_s 
(Gaithersburg,  15-17  Karch  1932),"  pp.  315-321. 


Legal  operands  of  the  HE'_P  operator  are  A,  B,  C.  0, 
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P  '-ginning  display  >_  croon  of  dem  onstration. 

Display  of  friendly  units. 

Display  of  DIVAD  fire  units. 

Battlefield  situation  display. 

Unit  symbology  using  geometric  shape  coding. 

User  prompt  to  select  battlefield  area  for  INSPECTion. 
Auxiliary  map  display  with  geometric  shape  coding. 
Auxiliary  map  display  with  standard  AD  symbology. 

Beginning  of  update  of  friendly  unit  location. 

Completion  of  update  of  friendly  unit  location. 

Display  of  Kill  Report. 

Display  of  Battlefield  Geometry  FLOT  definition  message. 
Display  of  Air  Defense  Warning. 

AD  3tatua  display  following  user  acknowledgment  of  message 
receipt. 

Display  of  Weapon  Control  Order. 

WCO  status  following  user  acknowledgment  of  message 
receipt. 

Activation  of  COMPOSE  MESSAGE  function. 

Selection  of  addressed  unit  for  MOVE  ORDER. 

Submenu  of  A  BTRY  assets. 

Selection  of  A  BTRY  weapons. 

Menu  for  selection  of  new  location. 

Entry  of  LINE  selection. 

User  prompt  to  select  battlefield  area  for  new  position. 
High  resolution  display  for  point  specification. 
Designation  of  first  point  of  line. 

User  prompt  for  entry  of  second  point  of  line  definition. 
Mission  selection. 

Time  specification  for  Move:.’ ?nt  Order. 
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